Skip to content
Published on

本番の感覚 — 障害を経験した人が違って見ているもの

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

経験した人は何を違って読むのか

同じ設計文書を二人が読みます。一人はこの機能がどう動くかを読みます。もう一人は同じ紙面から別のものを読みます。これが未明の三時に壊れたらどんなログが残るか、戻すのに何分かかるか、戻したあとすでに入ったデータはどうなるか。

二人目が賢いわけではありません。一度やられただけです。そしてこの差は知識としてではなく既定値として現れます。知っているかどうかではなく、聞かれる前に確かめるかどうかです。だから本番の感覚は試験で測りにくく、設計レビュー三十分で露わになります。

本番はコードではなく状態です

コードはリポジトリにあり版は一つです。本番は状態であり版はいくつもあります。いま回っているイメージ、いま当たっている設定、先月誰かが手で変えてどこにも書かなかった値、三年積もって文書とは違う形になったデータ、いま開いている接続の数。このうちリポジトリが知っているのは最初の一つだけです。

だから自分の環境では動く、は冗談ではなく正確な記述です。違う状態で走らせたから違う結果が出たのであり、この差を詰めることが運用の大半です。

ここで第3回の結論が戻ってきます。動いているシステムは自分自身についての最新の文書です。本番の感覚の半分はその文書を読む習慣であり、残り半分はそれがコードと違いうるという事実を常に計算に入れる習慣です。

100パーセントは正しい目標ではありません

GoogleのSRE本でリスクを扱う章はこう言います。100パーセントはおそらく決して正しい信頼性目標ではない、達成が不可能なだけでなく、利用者が望みも気づきもしない水準の信頼性だからだ、と。

同じ章は代価も書いています。安定性を最大化すると新機能を作る速度が制限され、製品が利用者に届く速度が落ち、費用が大きく上がります。しかもその費用は線形には増えず、信頼性を一段上げるのに前の一段の百倍かかることがあると記されています。

ここから出てくる装置がエラーバジェットです。目標と100パーセントの差を、その期間に使える不安定さの予算として扱います。この装置の本当の価値は計算ではなく会話にあります。どれだけ安定していればよいかが、好みの争いから数字の問題に変わります。そして数字の問題になれば、開発と運用が互いの反対側に立たなくなります。

可観測性・ロールバック・段階的リリースは道具ではありません

この三つはたいてい製品名と一緒に紹介されますが、実際に人を分ける点は道具ではありません。

可観測性は何を入れたかではなく、デプロイの前に、これが失敗したらどこを見ればよいかの答えがあるかどうかです。ダッシュボードが二十枚あっても、その問いに答えが無ければ可観測性は無いのと同じです。

ロールバックはコマンドがあるかではなく、戻せる状態を作ったかどうかです。スキーマを前の版が読めない形に変えてしまったなら、コマンドはあってもロールバックはありません。戻せるようにする仕事はデプロイの瞬間ではなく設計の瞬間に決まります。

段階的リリースは比率を割る機能ではなく、止める基準を先に決める仕事です。5パーセントに入れて様子を見よう、という計画には何を見たら止めるかが抜けており、それが無いと人は様子を見たあとそのまま全体へ行きます。

例 — デプロイ前に埋めておく四行

悪化と判断する基準: どの指標がどの値を超えたら
どこで見えるか:     その指標を見るダッシュボードやログ検索
止める時点:         何分観察し、どの値なら中断するか
戻したらデータは:   戻せるか、戻せないなら何が残るか

四行を埋めずにデプロイすることが必ず悪いわけではありません。ただそのときは、デプロイではなく実験をしているのだと分かってやるほうがよい。

速度と安定性を引き換えにするという誤解

よくある前提があります。頻繁にデプロイするほど危ないので、安定を望むならゆっくり行くべきだ、というものです。

DORAが公開している指標の案内は逆を言います。デプロイ頻度、変更リードタイム、失敗したデプロイの復旧時間、変更失敗率、デプロイ手戻り率の五つを並べると、ほとんどのチームで指標は互いに相関しており、上位のチームは五つすべてで良く、下位のチームはすべてで悪い、と。同じ文書は速度と安定性が引き換えではないと明記しています。

この観察を因果として読んではいけません。相関は向きを教えず、組織の別の要因が五つを同時に押し上げた可能性もあります。ただ構造として読めることはあります。安全にする仕掛けと速くする仕掛けは、たいてい同じ仕掛けだということです。戻せるなら頻繁に出せ、頻繁に出せば一度に入る変更が小さく、変更が小さければ壊れたときの容疑者が少ない。

経験せずに学ぶ三つ

本番の感覚を得る最も確実な道は大きな障害を経験することで、それは勧められる学習計画ではありません。代わりに使えるものが三つあります。

一つめは他人の障害報告を読むことです。素直に読むと他人の話で終わるので順序を変えます。時系列の記録だけを先に読み、その時点で自分なら何をしたかを決め、それから残りを読みます。自分の答えと実際が分かれた点が学ぶところです。

二つめはオンコールに入ることです。通知を受けた人は通知を違うふうに設計します。一度もオンコールに立ったことのない人が作った通知はたいてい多すぎ、多ければ無視され、無視されれば無いのと同じです。

三つめはわざと壊してみることです。時間を取って依存しているものを一つ止め、チームがどれだけ早く気づくかを見ます。ここでたいてい驚くのは復旧時間ではありません。誰も気づかなかったという事実です。

手を動かす

今週出るデプロイを一つ選び、上の四行を出す前に書いておいてください。五分で足ります。四行のどれか一つでも書けないなら、その行が今回のデプロイで最も危ない部分です。

  • SLO エラーバジェット 計算ツール — 可用性目標を許容ダウンタイムと予算に変えてみると、いまの構成でその目標がそもそも可能かが計算で出ます。依存先の可用性が掛け算になる点がとくに痛い。
  • Linuxターミナルシミュレーター — 動いているシステムの状態を手で確かめる操作を安全に繰り返せます。可観測性は道具を買う前に見る習慣です。

通じない場合も書いておきます。まだ利用者のいない製品や社内だけの道具では、デプロイ手順を厚くするほど学ぶ速度が落ちます。この段階で実際に価値があるのは四行のうち最後の一つだけです。データを戻せるか。残りは利用者ができてから足しても遅くありません。

続けて読む

高いまま残る技術シリーズ

参考資料

  • Embracing Risk — Google SRE Book — 100パーセントはおそらく決して正しい信頼性目標ではなく利用者が望みも気づきもしない水準だという文、極端な信頼性が開発速度を制限し費用を大きく上げるという論拠、信頼性を一段上げるのに前の一段の百倍かかりうるという記述、そしてエラーバジェットの定義がここから来ています。2026-08-15閲覧。
  • DORA metrics: the four keys — dora.dev — 五つの指標の定義と、速度と安定性が引き換えではなくほとんどのチームで指標が相関しているという記述がここから来ています。2026-08-15閲覧。
  • デプロイ前の四行と、経験せずに学ぶ三つの方法は上記資料にあるものではなく、この記事でまとめたものです。
Discuss on Twitter • View on GitHub