業務時間外に障害対応しなくて済むようにしていること

仕事

結論から先に書くと

  • 夜間のcron実行はなるべくさける
  • 金曜デプロイ禁止

です。


なぜ我々は業務時間外、主に酒を飲んだり寝ている時に障害対応をするハメになるのか - oranie's blogを読んで自分が思うことをつらつらと書いてみます。

コンテキストをはっきりさせた方がいいのでそれについてまず書きます。

僕の場合はB2C向けのサービスが出しているログを収集して定期的にバッチ実行しKPIを自社内にレポーティングするという仕事をしています。

要するに社内システム担当です。コストセンターとも言いますね。

その意味で本番サービスと比べればサービスレベルは低くてもまだ許されます。別に障害が起きていいわけではありませんが、安定性を重視しすぎて新しい統計値を取得するための開発が遅れてはダメですからね。

本番サービスのピーク時間帯が22時台なのでログ収集の負荷もその時間帯に高くなります。クックパッドは16時がピーク時間帯だからエンジニアにやさしいなんて話をどっかで見た気がしますがそういう会社は少ないですよね。やっぱりどうしても普通のビジネスパーソンが仕事終わった後の余暇の時間帯、22時とか23時がピーク時間帯というWebサービスは多いんじゃないでしょうか。ソーシャルゲームとかも多分そうですよね。

逆に負荷が低い時間帯は朝の3時とか4時になります。なので負荷の低い時間帯のcronジョブとかもあったのですが、ある時そのジョブが動かなくて時間が時間だけに気づくまでに長くかかったことがありました。で、よく考えると、別にピーク時間帯じゃなければいつ実行してもいいようなジョブだったので午後3時とかの業務時間帯に実行するように変更しました。

僕の仕事はログデータを集計する定期バッチがちゃんと動けばまあだいたいOKなのですが、バッチもいろいろあって夜間の一番長いバッチは5時間くらいかかります。前日のログデータが出そろったら実行するのでこのバッチは必然的に深夜になります。例えば1/24のPVを知りたいんだったら1/25に集計処理を実行しないといけないですからね。

この夜間バッチがこけると朝には、「データがないぞ、ごるあ！」みたいなメールを出社したら見ることになります。平日だったら普通に対応するわけですが、週末だとつらいですよね。なので金曜日にはこの夜間バッチが影響するような修正をデプロイすることは基本的にありません。金曜日はbeta環境で作業するのがいいですね。

金曜日がダメなら木曜日でいいかっていうと修正規模によってはそれもちょっと微妙ですね。なぜかというと予備日が1日しかないから。小規模な修正ならいいですが、大規模な修正はちょっと考えた方がいいかも。以前木曜日にHadoop,HBase,Hiveのバージョンアップをやって木曜日の深夜バッチがうまくいかなくて金曜日に対応したんですけど、金曜日に対応した分のバッチ修正は金曜深夜実行のバッチに入るわけでこれだと要は金曜デプロイとやってることあんま変わらないですからね。

デプロイしてすぐ確認できるものならまだいいんです。例えばhourlyバッチだったら割とすぐ動作確認できるのでまだいいんですが、夜間バッチだと修正したらその確認は次の日までわからないんですよね。もちろんbeta環境で動作確認するんですが、betaと本番ではデータ量が全然違うのでちゃんとしたテストはできないんですよね。

自分が開発した新機能をすぐデプロイしてすっきり週末を迎えたいという気持ちは分かるんですが、少なくとも金曜デプロイは止めた方がいいと思います。そして大規模な修正だったら月、火、水のどこかでやるのが良いと思います。まあそうもいってられないときはあるでしょうけど。