Webサイトの障害からの教訓：エンジニアの対応失敗事例とその学び
哈儸大家好！あっきーです。
お久しぶりです。
今回は「Webサイト周りの障害対応」について、1つ書いてみました。
この投稿の背景
少し前の話ですが、私たちが管理する、サイボウズのWebサイトに関わるシステムで、2件の障害がありました。
それぞれ対応して解消はできたのですが、自分の立ち振る舞いに反省があったので、具体的な振り返りもかねてこのnoteを書いています。
前提として、
私はエンジニア出身で、現在もサイボウズのWebサイトにおけるエンジニア目線での業務をよく行う
でも、所属する部署はビジネス系のマーケティング本部で、周りには非エンジニアの方が多い
という状況だと知っていただけると話が入りやすいかもです。
※参考↓
エンジニアとしての障害対応の原点
せっかくなので、「そもそもエンジニアの障害対応ってどんな風にやるんだろう」という部分について、先に書いてみます。
ます、私がエンジニアとして障害対応をする上で、一種の「理想」であり「原点」となっている経験があります。
それは、エンジニア2年目でお世話になった、とある小さなWebサービスの会社でのことです。
後で紹介する「今回あった障害」と、あまり関係ない部分もありますが、こちらも一つの「事例」として紹介できればと思います。
障害対応時の体制って大事
（そもそも良いのかどうかはさておき、）その会社ではしばしば障害アラートが鳴ることがあり、その度にエンジニアチームはすぐに対応にとりかかっていました。
まず誰かがアラート検知し、周りに声をかけます。
アラートから影響範囲を確認し、各プロダクトチームが調査を始めます。
それと平行して、一人のチームリーダーは、関連するビジネス系部署に連絡をいれ、専用タイムラインに障害の状況をまとめ出します。
各チームで原因がわかったら、それに対して適切な対応をとります（それらは都度まとめ役のチームリーダーに伝達されています）。
もちろん、複雑な要因のことや、サーバー機器本体の問題で長引くこともありますが、その場合は今後の対応をどうするか、関係各所と協議を行って対応していきます。
超ざっくりでこんな感じでしたが、この会社は「体制（※言い換えるなら「役割分担」とも言えます）」がめちゃくちゃ洗練されていたと思います。
障害は、様々な要因によって生じ、多種多様な事象が起こりえますが、この経験から、「適切なフローと体制を組んでおく」ことが基本ではないかと考えるようになりました。
比較的小さな会社だったことや、リモートとなる前の世界だったので、このあたりの連携が容易だった面はありますが、それでも素晴らしい対応（特に初動）だったなぁと思っています。
障害に向きあうマインド「事実に基づき、『犯人捜し』をしない」
もう1点、その会社であった出来事を紹介します。
先ほどは、障害対応に取り組む「チーム」としての話でしたが、こちらはどちらかというと、障害対応にあたる「一個人」としての経験です。
ある障害が起きたとき、こんな会話（ざっくり記憶）がありました。
リーダー「障害起きました～。xxxのシステムが落ちています」
メンバー「ならたぶん、Aさんがさっきリリースした部分が起因ですね」
リーダー「今、その発言は違う。犯人捜しではなく、今は調査で事実のみを集めてくれ」
自席の目の前でパッとこの会話があったのですが、その時はピンと来ていませんでした。
ですが、その時の障害は、結果的にもう少し広範囲にわたるもので、厳密には「Aさんのリリース」で表面化しただけで、そこの改修だけでは解消しない内容だったと記憶しています。
このことから、下記の2点をとても重要視するようになりました。
調査の「勘所」にするのはいいが、決め打ちは危険で、「具体的な調査結果（事実）」に基づいて議論が必要。
「Aさんが～」の発言は「犯人捜し」に該当し、結果的にチームの心理的安全性を損ねる。重要なのは、「バグを憎んで人を憎まず」。
今回の障害を振り返る
長々と前置きをしましたが、ここから今回起きた実際の障害対応について振り返っていきます。
今回主に私が反省しているのは、いずれも障害発生時の「初動」についてです。
障害1：調査に集中しすぎて障害を長引かせちゃったパターン
この障害は、私たちが管理している、Webサイトの更新管理システムでのことです。
※該当のシステムはこちらを参照ください
このシステムで、とある設定変更を行う必要が出ました。
テストサイトの表示に関係し、利用者にも影響があるものなので、作業日を事前周知をして、いざ反映。
ですが、その設定がなかなか反映されず、作業日以降、利用者さんからも「テストサイト見えないんだけど、設定ちゃんと変わっている？」との問い合わせが多発。
自分も原因調査に取り掛かりますが、一向に理由がわからず、事象も解消しません。
設定変更の内容的にも、設定反映から障害事象発生までタイムラグがあるタイプなのもあり、トライ&エラーでやっていると、ずるずると日付が過ぎていってしまいました。
いちおう「暫定対応」で、テストサイトが見えるようになり、更新作業がどうにか進められるにはしましたが、利用者さんの混乱を招く状態は1か月ほど続いてしまいました。
最終的にサポートにも問い合わせ、原因は「使っているシステム元のそもそもの仕様（※バグではなく、本来公式ドキュメントにあるべきはずが、どこにも書いてなかった類のもの）」で、別の設定変更を行ったうえで再度実施するとうまくいきました。
ということで、この障害での反省は、下記二つです。
もう少しうまく役割分担（調査、問い合わせ、周知）できればよかった。障害対応は個人でやるのではなく、「チーム」で、「適切なフロー」で進める。
「エンジニア目線」で、初動の「調査」に時間をかけすぎた。もう少し、利用者が困らないようにする対応を優先すべきだった。
正直、前者は現状難しい部分もあるのですが、今後の体制も含めた課題だと感じました。
障害2：調査の「事実」集めを怠り、原因究明に時間がかかったパターン
一方で、もう一つの障害は、あまり「エンジニア目線」を働かせなかったが故の反省です。
障害が起きたのは、コンテンツの配信システムだったのですが、こんなアーキテクチャ↓をしていました（超ざっくりで、一部わかりやすくしています）。
```mermaid
flowchart LR;
subgraph システムA;
A1;
A2;
A3;
end
subgraph システムBC;
A1==>|コンテンツ配信|B1;
A2==>|コンテンツ配信|B1;
A3==>|コンテンツ配信|B1;
B1-->|定期的に同期|B2;
B2-->|コンテンツを、C経由で利用者へ配信|C;
end
C==>利用者;
```起きた障害の内容は、「新しくA3を追加したが、利用者に正しくコンテンツが配信されなかったこと」でした。
さっそく、非エンジニアの関係者も含めて議論が始まりましたが、結果的にこんなことになってしまいました。
新しく作ったA3は、今までのA1や2と同じ配信設定になっている。
システムBC側の受け入れ設定がうまくいっていないのではないか。システムBC側に問い合わせたほうがいい。いや、システムBC側は、すべて使いまわしで、今回も同じ設定になっている。システムA側の設定が間違っているのではないか。むしろそっちに確認したほうがいい
こうなってしまうとどうしようもないので、実際にじっくり調査をしてみます。
そうすると、意外なことに、配信出来ていない一番の原因は、「『システムC』のもともとの仕様」だったことがわかりました。
では、どうしてこれまでA1や2でうまくいっていたかというと、たまたまそれが発生しないパターンだっただけで、新しいA3ではそれが発生するパターンだったわけです。なので、システムA3からの配信設定も、システムBC側の設定もすべて問題がなかったのです。
最終的には、システムA側設定に調整を入れることで、意図する配信ができるようになりました。
こういったパターンはよくあるのですが、結果的に思ったより時間を取ってしまいました。
ということで、この障害での反省は、下記です。
「エンジニア目線」を怠り、障害の影響範囲と直前の作業から、つい「勘所」先行の議論をしてしまった。正しくは、初期段階からすぐに、障害による現状の「事実」を追いかけるべきだった。
上記に関連し、原因を見つける際、システムの設定についての「作業者」起因での議論（犯人捜し）をしてしまった。バグを憎んで人を憎まず。。。
このように前述の「障害に向きあうマインド」で書いた理想とはかけ離れており、エンジニアとしては、自身の対応に反省の多い障害でした。
まとめ：二つの障害を通して学べること
最後に、改めてこの二つの障害を俯瞰して振り返ると、学べることとして「エンジニア・利用者目線のバランス」「何かあった時の体制の準備」があるかなと思っています。
エンジニア・利用者目線のバランス
先に紹介した障害事例について、
「障害1」では、「利用者目線」を忘れて、つい原因調査に没頭してしまったことが長期化の原因になりました。
一方で、「障害2」では、「エンジニア目線」を忘れて、正しく障害対応を進めることを怠ってしまいました。
どちらの目線も、障害対応においては重要なので使い分けることも必要ですが、それぞれの「バランス」が重要だと思いました。
そして、「エンジニア目線」の時は、「事実に基づき調査し、『犯人捜し』をしない」というマインドも、忘れないようにしないといけないですね。
何かあった時の体制の準備
一方で、「バランス」ってどんな時も忘れてはいけない感覚だと思いつつ、一人でやるとめっちゃ難しいものであることも事実だと思います。
そのために、それぞれの「目線」を持つメンバーが集まり、すぐに助け合える「チーム体制」を作っておく必要があると思います。
障害は、内容が大きければ大きいほど、一人では解消するものではありません。
その時、「調査・対応に集中する人（エンジニア目線）」「影響範囲を確認し、関係各所と連携取る人（利用者目線）」「それらをサポートする人（バランス係）」…etc、みたいな役割分担ができると、とてもいいかなと思っています。
そして、これに関連し、障害時などの対応フローも、それぞれが理解しておくようになればベストだと考えています。
そのためには、フローの明文化や、意識あわせのチームMTG、定期的な訓練などが必要になってくるかなと思います。
※参考：私たちチームでも、定期的に見直しを行っています！
いかがだったでしょうか。
今回2件は、どちらも軽微な障害だったので比較的心穏やかに振り返れますが、そうでなかったと考えると。。。
ということで、日本列島猛暑の中、「障害対応」についての、少し背筋の寒くなる話でした。
それではまた！
※この投稿の見出し画像は、Loose Drawingさんを利用させていただきました。