障害対応を起点とした もっといい開発と運用の サイクル作りのためにできること id:polamjag 2024-04-24 Hatena Engineer Seminar #29

whoami ● id:polamjag 《ポラムジャグ》 ● Webアプリケーションエンジニア

話すこと ● いちアプリケーションエンジニアとして、発 生してしまった障害にどう向き合うか ○ (職種を限定したいわけではない) ● 前提: 障害は起こってしまうものである ○ し、障害対応を100%自動化するのは難しい ○ (人間に、あるいは自分にできないことを自動化する のもいまは難しい)

障害は起こってしまう かもしれない なるべく早く復旧させたい

(短時間で) 自動で復旧する 短時間のうちに人力で復旧できる 復旧に時間がかかる 永久に直せず朽ちていく

(短時間で) 自動で復旧する 短時間のうちに人力で復旧できる 復旧に時間がかかる 永久に直せず朽ちていく これが最高 󰢛󰢛 󰢛 😇😇😇 😇

(短時間で) 自動で復旧する 短時間のうちに人力で復旧できる 復旧に時間がかかる 永久に直せず朽ちていく

(短時間で) 自動で復旧する 短時間のうちに人力で復旧できる 復旧に時間がかかる 永久に直せず朽ちていく 早押しクイズ…？

障害対応 = 早押しクイズ 説 ● 原因や解決策を高速に特定できるのは良いが ○ (解決策の実行自体に時間がかかる場合もあるとは思 います) ● 早押しで答えられるクイズの答えって暗黙知 に閉じていないか？

暗黙知 ● 必ずしも「暗黙知 = 常に悪」ではない ○ チーム全員の暗黙知にできていて、かつチームに新し く入ってきた人でも困ったりしてないのであれば問題 ないはず ● ナレッジマネジメントの話として捉えてみる

答えにたどり着くまでの知識 ● 状況認識・分析のための情報 ○ アラートやお問い合わせ、あるいはログとメトリックなど ○ これらそのものや、これらに関するドキュメントなど ● 状況の原因を見極めるための情報 ○ こういうときはたぶんこう、という情報 ● 原因と解消・復旧方法のセット ● = 何があったときに何をすべきか

障害対応ナレッジと暗黙知・形式知 ● 暗黙知: アラートを見て対応方法が頭に浮かぶ ● 形式知: Runbook、あるいは参考にできるポ ストモーテムなどのドキュメントの存在 ○ (形式知があるという暗黙知: アラートを見て、対応方 法が書いてあるドキュメントを思い出せる and/or す ぐに見つけられる)

形式知と暗黙知を育てる → SECIモデルのサイクル

暗黙知 形式知 創発場 システム場 実践場 対話場 連結化 Combination 形式知を結合 内面化 Internalization 形式知を会得 共同化 Socialization 暗黙知の共有 表出化 Externalization 暗黙知の言語化 SECIモデル

はてなにおける 取り組みの例 暗黙知 形式知 創発場 システム場 実践場 対話場 連結化 Combination 形式知を結合 内面化 Internalization 形式知を会得 共同化 Socialization 暗黙知の共有 表出化 Externalization 暗黙知の言語化 ● 障害対応後のふりかえりの実施 ● ストモーテムを社内で共有し チーム横断社内勉強会で眺める ● チームごとにインフラ見る会で 話題にする (PWG はてな で検索) ● ドキュメントを書く時間を チームで定期的に確保 ● 障害対応演習 SECIモデル

暗黙知を共有する仕掛け ● Mackerel ○ カスタムダッシュボードに注釈を書きまくる ○ 監視ルールにメモができるので、監視の意図・経緯や アラート発報時の対処法を説明する ■ ref. 「Mackerelのメモ機能、活用してますか？」 https://blog.arthur1.dev/entry/2023/12/04/070000 ○ 障害対応後のふりかえりや、PWG (チームでインフラ見る会) の場などでガンガン追加・編集

Mackerelの監視ルールのメモ

ナレッジのその先: unknown unknownへの対応 ● Observabilityの世界 ○ 未知の状況での早押しクイズのためのヒント、仮説 ■ 障害対応時で原因なりを探索した経験があると、どういうヒ ントが嬉しいのか (あるいはそこまで嬉しくないのか) わかる ■ どこでどうobservabilityを高めると嬉しいのかという知識 は、これまでに話したような内容であるはず

まとめ ● システムの開発・運用、障害対応を知識創造 活動として捉えてみる ○ 障害を起こしてしまったときは、自分たちのナレッジ を点検するチャンス ○ /(自分|チーム)が持って(いる|いない)知識/ の差分を 考え、どこから埋めるべきか考えることで、もっと いい開発と運用のサイクルを回そう