SRE 向けの根本原因解析 Github テンプレートを作った話

背景

SRE エンジニアとして、2年以上働いているとパッとでは理解できない問題に遭遇することがあります。

そうしたときに、「もっと体系的に、（ソフトウェアエンジニアなら）誰でも調査が進められるテンプレート」が必要だなと感じました。

また、SRE の業務をスクラムで行っていたりすると、こういったシステムのトラブルの調査は見立てが立てづらく、どのように着手して、AC (Acceptance Criteria) を設けるかかという話がしにくいです。

そんなとき、システマチックに調査が行えれば、「テンプレートの内容を埋め、仮説とその評価を行う作業についてチケットを切る」という使い方ができます。そうすれば、ある程度はスクラムのやり方に沿った進め方ができます。（例：スプリントレビューでこの仮説と評価について共有されていること）

大学院で研究を少しかじっていた身からすると、システム障害はそれに近しいものがあると感じました。

仮説をたてて、そのための証拠となる客観的なデータを集めることを繰り返します。

ただ SRE として行う場合には、「代替案や暫定対応はないか？」という視点を同時に持っておく必要があるのが研究と大きく異なるところです。

直接的に障害を起こしたものを真因 (True Cause) とすると、それを潰すことだけでは再発防止になりません。

例えば、高負荷はよくシステム障害の原因になりますが、ハードウェア増強で一見解決したように見えても、しばらくするとまた同じ障害になることがあります。

再発防止のためには、パフォーマンスを分析するフローを確立したり、モニタリングの強化とそれにともなうハードウェア増強のルールを策定したり、あるいは負荷の要因となるプログラムの見直しなど、行えることはたくさんあります。

限られた資源（時間、人、金、モノ）のなかで有効な施策を行う必要があります。