kachick / times_kachick

`#times_kachick channel in chat` as a public repository. Personal Note and TODOs
https://github.com/kachick/times_kachick/issues?q=is%3Aissue+is%3Aclosed
6 stars 0 forks source link

2021-06-20 - 付け焼き刃の危機管理 #133

Closed kachick closed 3 years ago

kachick commented 3 years ago

佐々淳行さんが2018年に亡くなったのは、やっぱり Twitter かなんかで知ったんだと思う。

2005年ぐらいから2010年ぐらいまで?佐々さんの書籍を追いかけている時期があった。 その流れで、後藤田正晴さんの事も知った。 メールから追ってみると、少なくともこの辺は買っていそうだ。

うっすら思い出せるのもあれば、え、こんなの読んだっけ?というタイトルもあるので、積読してた物もあるかもしれない。 政府で働いてた方だから思想信条がある程度混じってくるのはまぁそういうものだろうなぁぐらいに思っていて、むしろ「割とその辺抑えようという姿勢で執筆される方だな」と感じていた。

自分が当時興味を持っていたのは「危機管理」についてだったと思う。 ネットワークエンジニアっぽいところからエンジニアっぽいキャリアを始めたので、「障害対応」というのに割と縁があった。 当時「障害発生時はこう対応しましょう」みたいな書籍があまり見当たらなかったのか、もしかすると「薄く」感じたのかも知れない。技術的な話が知りたいというよりも、そういうてんやわんやの事態になった時にどういう心構えで対処すると良いのかとかその辺が知りたかった。

その手のソフトスキル的な話では、近年出版されるエンジニア向けの本や学者の研究結果、自己啓発っぽい本だけを頼りにする必要は別に無いんじゃないかなという考えを当時も今も持っている。哲学だの諸子百家だの仏教だのの古くから実際に活用されて来たような物の中から、適当につまみ食いしても良いんじゃないの?という発想だ。

とはいえ古すぎる本は抽象的過ぎてちょっと使いづらいところもあったので、どうしたもんかなーという時に目を付けたのが佐々さんだった気がする。 割と正解だったみたいで、障害対応と縁深い間、同僚や上司と比べてすらうまく凌げた方だったと思う。

これだけ抑えておけばオールオッケーみたいなシンプルな話が少なかったこともあって、今でも覚えている事は殆ど無い。 ただ、 後藤田五訓 は印象的なので記憶に残っている。やっぱり「短く言い切る形の言葉は強い」なぁと思う。

  1. 出身がどの省庁であれ、省益を忘れ、国益を想え
  2. 悪い、本当の事実を報告せよ
  3. 勇気を以って意見具申せよ
  4. 自分の仕事でないと言うなかれ
  5. 決定が下ったら従い、命令は実行せよ

「責任分界点」みたいな単語が飛び交う職種だった事もあって4番はちょっとアレだったけれど、他に関しては割と実践出来てた気がする。当時の自分は偉いなぁと思った。

kachick commented 3 years ago

https://quipper.hatenablog.com/entry/2019/11/27/080000/incident-response-and-postmortem

そういえば、その辺りを本業というかもっとちゃんとした形で取り組んでいる同僚が良い記事を書いていた。自分の当時の付け焼き刃的に身につけた範囲の浅い経験からも、全てが心に染み入る。 以下引用させてもらう。


障害対応への心構え

これまで、障害が発生したときの流れを説明しました。これらを実際にやるには知識だけではなく、経験が必要です。

(残念ながら)いくつか障害対応を経験してきた中で、大事だと思うことをいくつか紹介します。

落ち着く

これが一番大事です。

起きてしまったことは仕方がありません。上記で述べたようなやるべきことを確実にやるべきです。

障害対応はリアルタイムに影響が発生していることもあり、プレッシャーを感じてしまうひとも少なくないと思います。(もちろん私もそうでした。)しかし同時に、障害対応は複雑な状況から起きた原因を究明したり、失敗が許されない本番環境での Manual Operation が発生したりと、非常に難易度の高い仕事です。

そういった仕事を確実にこなすためにも、落ち着くことが何より大事です。(楽観視するという意味ではなく、冷静であるという意味です。)

役割分担する

最低限、以下は分けたほうが良いでしょう。

ある日の障害対応では、上記のように役割分担を行うことで非常にスムーズに解決を行うことができました。役割を分担し、それぞれリードを行うひとを決めることで、それぞれの関心事項に関して周囲のひとが協力して解決を行うことができました。

現場を指揮統率するひとは主に判断と担当へのアサインを行います。システムを熟知していて、ステークホルダーをよく知っているひとが適当でしょう。

障害内容を報告するひとは、Developer に協力を仰ぎ影響範囲や障害内容をまとめながら、ステークホルダーにメールを送ったり Slack によって報告を行います。ビジネス・プロダクトの責任者が適当かもしれません。

復旧・原因究明をするひとはおそらく SRE や Developer となるでしょう。

ポストモーテムを書くひとは、現場を指揮統率するひとが兼ねてもいいでしょう。

ひとではなく問題に向き合う

後述する ポストモーテムにおける Blameless Culture のことです。

原因究明や再発防止のプロセスでは絶対に特定個人の振る舞いに注視しないようにします。

「起きた問題」に対して、チーム全員で解決に向かって建設的に向き合いましょう。