Webサービスの障害対応のときの思考過程 - ぱいぱいにっき

起こってほしくはないのですが、あらゆるWebサービスは完璧に動作する状態を維持することは難しく、やはり障害対応・トラブルシューティングといった作業が発生します。 筆者は普段仕事で障害対応を不幸なことによくやるのですが、障害対応のスキルというのはスピードや判断の正確さが求められるせいか、今までやったことがある人・ノウハウがある人に集中し、それ以外の人は眺めるだけ・あとからログを見返すだけの状態によく陥ることがあります。 これはWebサービスを開発・運用するチームとしてみたときにそういった苦労が特定の人に集中するのは良くないので、それを緩和する目的として、筆者が障害対応時に考えていることを記述してみます。なお、これが唯一の正解ではないとは思っているので、ツッコミや、自分はこう考えているよというのを教えていただければ幸いです。 具体的な手法を避けて思考の方法を述べているのは、障害というのはパター

[yug1224]

ぱいぱいにっきって、どんな日記かと思った

[ducktoon]

仕事だと責任追及や圧力だけかけてくる人たちの存在が邪魔なんだよなあ

[hiboma]

特定の条件でバグるコードが潜在し、ある日　突然「発症」して障害を起こすケースは、病気のメタファーと相性よさそう。 ( 『デバッグのデバッグの理論と実践』 でも「感染」のメタファーで説明してた　 )

[issm]

[障害」

[maemuki]

前に働いてた会社のサービスに障害が見つかった時にはまず「はまちや？」と思考していました…

[tpircs]

やってるだろうけど、急性期リストアップのところに「いつから発生したか」「その前後で変更したことは何か」を探るってのもある気がする。

[kutakutatriangle]

いいまとめ

[tatematsu_san]

「普段の状態」の視認性を高くしておく必要はあるなと思います。ビジュアライズしかり、判断基準を含めたテキスト化然り。そうでないと追体験難しい。

[onesplat]

いい話。アプリケーションエンジニアが、永続データがぶっ壊れるような障害が起きる可能性を常に想定しながら作るのが大事

[ikkitang1211]

急性期までは結構得意。 ダメージコントロールの所で割と｢不具合修正 or リバート｣ しがち。 不具合修正する時は簡単なものはいいけど難しい場合ちゃんとリバートの判断とか他の判断が出来るようになりたい。

[nkzsdy]

ときどき読み返したい

[iekusup]

ほー。