まず止血する
前口上
Webサービスを運営していると気をつけていてもしばしば障害が発生してしまうことがあります。
全てのケースを網羅したつもりだったのにコーナーケースを考慮できておらずエラーとなったり、開発環境の少ないデータでは問題なかったのに本番環境でデータが増えるとパフォーマンスの問題で捌ききれなくなってしまったり色々です。
そういった障害は避けるべきものではありますが、やんごとなき事情により起きてしまう場合もあり、そういった際は障害の対応が必要になります。
よくある間違い: 自分の実装が常に正しいことを仮定してしまう
そういう意味で臆病さというか、駄目だった時のことをあらかじめ考えておくのは大切です。
データベースのスキーマの変更とアプリケーションの変更を一緒にしないだったり、大きめのライブラリーのアップデートと通常のデプロイを分けるだったり、切り戻しのしやすい変更に落とし込むのは良い進め方です。
人間はミスをする生き物で自分の実装が常に正しいことを仮定してはいけません。障害が起きないようにするのも一つのスキルですが、起きてしまった時に回復しやすい変更にとどめておくのもまた重要なスキルです。
よくある間違い: 完璧な修正をするために障害が長引いてしまう
障害時間は最小に抑える努力をするべきで、第一選択肢は変更をrevertする、切り戻すことだと思います。できない場合でも修正は障害を回復させる最小限にして素早くリリースしましょう。完璧な修正をするために障害が長引いてしまうケースもたまに観測します。
障害対応は
- ファーストエイド
- 恒久対応
の大きく二つに分けた方が良いです。
ファーストエイドは暫定の素早い修正です。問題の原因の根本解決を必ずしもする必要はなく、まず障害を止める、まず止血をする対応になります。
恒久対応はより根本の原因を修正した対応です。元々要求されていたものを満たしつつ、エラーとならない変更、問題の根本を解決した変更です。ファーストエイドより時間をかけても構いません。
最初のファーストエイドで恒久対応相当ができるなら構いませんが、人間焦っていると追加の失敗をしてしまうことも多く、一緒くたになって中途半端な修正になるくらいなら、明確に概念を分けた方が良いように思います。
よくある間違い: 同じ間違いを何度も繰り返してしまう
問題の修正が終わったら振り返りをしましょう。何度も同じことを繰り返してしまうのは学びがありません。失敗学というか失敗を共有することでチームのメンバー全体の底力が上がります。
ミスしたことを積極的には言いづらい場合もあるので、インシデント発生時の枠組みだったり、共有会の調整はシステマティックに行った方が良いかもしれません。
どうしたら再発を防止できるかしっかり議論しましょう。
よくある間違い: 障害対応をした人をヒーローにする
最後に語られることの少ないはまりどころについて書きます。それは障害対応で目立った人を必要以上に評価してしまう問題です。
障害対応はバグを出した本人が行わない時もありそれは素直に称賛されるべきものです。本人が出したバグを自身の対応によってリカバリーした場合でも、それ単体はナイスファイトでポジティブなフィードバックを送るのは良い文化です。
一方で、同じ難易度の開発において、バグなく機能を出せた人とバグを出してしまった人を比較した場合、明らかに前者が良い仕事をしているようにも思います。
障害対応をしていると目立ちますし、それを必死になってやっていると側から見るとコミット感があるようにも見え、そういった目立つ人が評価される会社も観測したことがあります。抜け漏れがあっても素早くリリースすることが要求されるケースもあるにはあるのですが、基本的にはまずバグを出さないを目指すべきです。
一番コードを書いている人が一番バグを出しやすいという論点もあるのでバランスが大事ですが、少なくとも障害を起こしても元気よく対応すれば評価されるみたいな風土が定着してしまうとシステムは安定化しないものです。
所感
以上です。ペアプロなんかも思うところがあるのでまた機会があれば記事を書きたいと思います。