Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
経験則で⾔えば、本当の意味で責任回避をしないポストモーテムはより信頼できる仕組み
を⽣み出す。
我々がポストモーテムの実践がSREの組織の成功を⽣み出し、また維持するのに重要だと
信じる理由である。
ポストモーテムの(組織への)導⼊は技術的な変...
ポストモーテムの哲学についての包括的な議論はSRE本の15章を参照。
このケーススタディは定期的なrackの廃⽌を特徴としており、 それがユーザーのサービ
ス待ち時間の増加につながった。
メンテナンスの⾃動化のバグと不⼗分なレート制限が組み合わ...
わずか数分の間に、全世界規模ですべてのサテライトマシンの ディスクが消去された。
マシンは不活性化され、ユーザーからの接続を受け付けることができなくなり、 以後の
ユーザー接続はデータセンターに直接ルーティングされるようになった。
ユーザーはわ...
ユーザー影響 : core(サテライト外)で代替処理された(応答遅延あり)
レベニュー影響: ⼀部広告はquery消失のためサービス不可となった 正確なレベニュー影
響は不明
検知 : 監視アラート
Resolution? : Divertin...
→ほとんどのサテライトマシンがディスク消去を停⽌するのに⼗分なほど、 オンコール
対応が速やかに動いていない オンコール対応が即時対応出来なかったのはこれが最初
ではない。
・幸運だったこと →コアがトラフィックを代替処理できる能⼒をもっていた...
いくつかのセクションで⾼度なサマリが含まれているが、 重要な詳細情報が失われてい
る
たとえば、、、
・Problem summary 障害が複数のサービスに影響を与えているので、 影響度合いを表現
するのに数字を⽤いるべき この例では、数字デ...
⼈間の⾏動を変更させることは⾃動化されたシステムやプロセスを変更するより信頼がお
けないものである
Dan Milsteinが語ったように 我々は皆、今⽇と同じくらいおろかである将来を想像しよ
う。
・優先度がすべて同じになっているため、最初に...
・Things that went poorly 「これは⾺⿅げている」といった⽣き⽣きとした表現
・Where we got lucky 「信じられない!」といった感嘆符のりよう
⽣き⽣きとした表現やドラマテックな表現は 主題部分から⽬をそら...
Upcoming SlideShare
Loading in …5
×

Ch10 pre

50 views

Published on

SRE workbook ch.10

Published in: Software
  • Be the first to comment

  • Be the first to like this

Ch10 pre

  1. 1. 経験則で⾔えば、本当の意味で責任回避をしないポストモーテムはより信頼できる仕組み を⽣み出す。 我々がポストモーテムの実践がSREの組織の成功を⽣み出し、また維持するのに重要だと 信じる理由である。 ポストモーテムの(組織への)導⼊は技術的な変化であるのと同じように、 ⽂化的な変化で もある このような変化を作ることは困難なことに思えるかも知れないが、 この章からの学ぶべ きことは、このような変化を作ることは可能であり、 また、克服できない挑戦のように は思えないということである。 Don't emerge from an incident hoping that your systems will eventually remedy themselves. 基本的なポストモーテムの⼿続きを導⼊することで、 ⼩さく始めて、⾃分の組織にあう ように変更し、調整することができる。 ※銀の弾丸はない。 よく書かれ、⾏動を起こされ、広く共有されている場合、 ポストモーテムは⾮常に効果 的なツールで、 組織にポジティブな変化をもたらし、障害が繰り返されないようにす る。 優れたポストモーテムのレポートの原則を説明するために、 この章では、Googleで発⽣ した障害のケーススタディを紹介する。 不適切なポストモーテムがなぜ、健全なポストモーテムを作ろうとする組織に 有害とな るかに焦点をあて、悪い例と良い例を⽐較する。 この章の後半では、インセンティブの構築について学んだことを共有する 強固なポスト モーテムの⽂化を育み、また、⽂化が崩壊しはじめていることを 初期兆候を認識(およ び対処)する⽅法について説明する。 最後に、ポストモーテムをブートストラップするために使⽤できる ツールとテンプレー トを提供する。 ポストモーテム⽂化(失敗から学ぶ) p.195 この章のポイント
  2. 2. ポストモーテムの哲学についての包括的な議論はSRE本の15章を参照。 このケーススタディは定期的なrackの廃⽌を特徴としており、 それがユーザーのサービ ス待ち時間の増加につながった。 メンテナンスの⾃動化のバグと不⼗分なレート制限が組み合わさり、 本番⽤トラフィッ クを伝送する何千ものサーバーが同時にオフラインになった Googleのサーバーの⼤部分は私たちの専有データセンター内にあり、 コロケーション施 設(colos)にもプロキシ/キャッシュマシンのRackがあります。 プロキシマシンを含むcolosのラックをサテライトと呼んでいる。 サテライトに対しては、定期的なメンテナンスとアップグレードがあり、 サテライト(の ラック)はつねに設置または廃⽌されている状況にあり、 そして、この保守のプロセスの ⼤半は⾃動化されている。 廃⽌のプロセスでは、diskerase(ディスク消去)と呼ばれるプロセスを使⽤して、 ラック 内のすべてのドライブの全内容を上書きする ⼀度、ディスク消去になると、過去に保存 したデータは⼆度と検索できない。 ⼀般的なラック廃⽌の⼿順は次のとおり。 # Get all active machines in "satellite" machines = GetMachines(satellite) # Send all candidate machines matching "filter" to decom SendToDecom(candidates=GetAllSatelliteMachines(),filter=machines) ケーススタディは、廃⽌予定のサテライトラックから始まる。 廃⽌プロセスのdiskeraseステップは正常に終了したが、 残りの部分は失敗に終わりまし た。 調査のために、廃⽌プロセスを以下のように再実⾏した。 # Get all active machines in "satellite" machines = GetMachines(satellite) # "machines" is an empty list, because the decom flow has already run. # API bug: an empty list is treated as "no filter", rather than "act on no # machines" # Send all candidate machines matching "filter" to decom SendToDecom(candidates=GetAllSatelliteMachines(), filter=machines) # Send all machines in "candidates" to diskerase. Case Study
  3. 3. わずか数分の間に、全世界規模ですべてのサテライトマシンの ディスクが消去された。 マシンは不活性化され、ユーザーからの接続を受け付けることができなくなり、 以後の ユーザー接続はデータセンターに直接ルーティングされるようになった。 ユーザーはわずかしか遅延を経験せずにすみ、再インストールに要した2⽇間で ほとんど のユーザーはこの問題に気付くことはなかった。 数週間かけて監査を⾏い、廃⽌作業のワークフローの冪等性を担保するために、 ⾃動化 にさらにsanity checksを追加しました。 障害から3年後、似たような事象を経験した。 たくさんのサテライトがドレインされ、ユ ーザーの遅延を引き起こした。 当初(3年前)のポストモーテムから⽤意されたアクションアイテムは、 劇的に影響範囲と 発⽣率を軽減させた。 あなたが、ポストモーテムの記述に責任があると仮定すると、 あなたは何が知りたいと 思うか? この障害が再び起こらないようにするために どのような⾏動を提案するか? あまり優れているといえないポストモーテムをまず⾒てみましょう Postmortem: All Satellite Machines Sent to Diskerase 2014-August-11 Owner : maxone@, logantwo@, sydneythree@, dylanfour@ Shared with : satellite-infra- team@ Status : Final(完了) Incident date : 2014-August-11 Published : 2014-December-30 ◇Executive Summary 影響範囲 : 全サテライトマシンがディスク消去となり、 (機械学習の)Edgeサービスが事 実上利⽤不可能になった 主要因 : dylanfour@が⾃動のセットアップ⼿順を無視し、 クラスターのturnupロジック を⼿動実⾏したところ、 潜在バグを踏んだ ◇Problem Summary 問題発⽣期間 : 40分 影響範囲製品 : satellite-infra-team 影響範囲(%) : 全サテライトのクラスター
  4. 4. ユーザー影響 : core(サテライト外)で代替処理された(応答遅延あり) レベニュー影響: ⼀部広告はquery消失のためサービス不可となった 正確なレベニュー影 響は不明 検知 : 監視アラート Resolution? : Diverting traffic to core followed by manual repair of edge clusters. ◇Background (optional) 記載無し ◇Impact ・User impact 通常サテライトで処理される、クエリーがすべて、 コア部分で 処理されたため、応答遅延があった ・Revenue impact ⼀部広告がクエリー消失で処理されなかった ◇Root Causes and Trigger クラスターの起動停⽌の⾃動⼿順は冪等性を保証していなかった。 ツールは特定の⼿順 が複数回実⾏されないというセーフガードを持っていた。 不幸なことに、 望む限りの回 数、⼿動でコードを実⾏することを阻⽌するものはなにもなかった。 この注意すべき事 はどのドキュメントにも記載されていなかった。 結果として、チームメンバーのほとんどが、そのプロセスを複数回実⾏することは 問題 無いと考えていた。 上記がラックの廃⽌⼿続きのなかで発⽣していたことです。 ラックは新しいIotaベースの サテライトに置き換えられつつあった。 dylanfour@はターンアップ⼿順はすでに実⾏され、 ⼀回⽬の実施でとまってしまってい たという事実を 完全に無視した。 ケアレスによる無視により、全サテライトマシンがディスク消去に割り当てられるという 悪しき相互作⽤に陥った ◇Recovery Efforts 記載無し ◇Lessons Learned ・うまくいった点 →監視により問題が即時に検知された →インシデントの管理はうまく ⾏われた ・うまくいかなかった点 →チーム(とりわけ、maxone@, logantwo@)がSREに⾃動⼿順 を複数回実⾏しないようにと伝える ドキュメントを⼀切書いたことがないといのは、ば かげている
  5. 5. →ほとんどのサテライトマシンがディスク消去を停⽌するのに⼗分なほど、 オンコール 対応が速やかに動いていない オンコール対応が即時対応出来なかったのはこれが最初 ではない。 ・幸運だったこと →コアがトラフィックを代替処理できる能⼒をもっていたこと 信じら れない! ◇Action Items ◇Glossary 記載無し 悪い例は我々が避けるべきたくさんの共通的な問題を含んでいます。 この節では、どのようにポストモーテムを改善すればよいかを説明します。 最初に、特殊な語法、「サテライト」のようなトラフィック処理固有、 あるいは、「デ ィスク消去」のような低レベルなマシン管理固有といった⽤語が⽤いられている点 ポストモーテムの中で追加の⽂脈を持つ場合、 BackgroundsかGlossaryを利⽤すべきで、 このケースではどちらも記載がない。 ※より詳細なドキュメントへのリンクでもよい ポストモーテムを書くときは、適切に⽂脈を補⾜できないと、 ドキュメントは誤読され るか、無視されることすら有り得る。 読者は直接のチーム関係者に留まらないことを覚えておくことは重要。 Action item Type Priority Owner ⾃動⼿順の改善 改善 優先度2 logantwo@ ページングと監視の改善 ⽋陥 優先度2 sydneythree@ needs to learn proper cross-site handoff protocol so nobody has to work on duplicate issues 改善 優先度2 安全でないコマンドを実⾏しないように訓練する 障害 優先度2 どう改善すべきか? Missing context
  6. 6. いくつかのセクションで⾼度なサマリが含まれているが、 重要な詳細情報が失われてい る たとえば、、、 ・Problem summary 障害が複数のサービスに影響を与えているので、 影響度合いを表現 するのに数字を⽤いるべき この例では、数字データは停⽌時間でのみ利⽤されている 障害の規模を推測する詳細情報が与えられていない。。 具体的なデータがないにして も、 よく知られた推測値は、データがまったくないよりは良い。 結局、影響度合いを測 る⽅法がなければ、直ったことをしることもできない ・Root causes and trigger 根本的な原因とトリガーを特定することは、 事後分析を書くための最も重要な理由の1 つ。 私たちの例は根本的な原因と引き⾦を説明する⼩さな段落を含みますが、 より、低レベ ルな詳細情報について⾔及していません。 ・Recovery efforts ポストモーテムは障害記録として扱われる 優れたポストモーテムは、読者に何がおり、 問題がどう改善され、どう影響をうけたのかを伝える。 これらの疑問の多くは、原則的にはRecovery Efforts節に記載されるべきだが、 この例で は空欄になっている 障害がポストモーテムにメリットをもたらせるように、時間を使うべき。 事象を正確に 表すため、必要な詳細情報を表現するためにです。 読者は障害の概要を知り、そしてよ り重要なことはそこから何かを得ることができる。 この例では、アクションアイテムが重要な再発防⽌のための実⾏可能なプランの重要な部 分の記載がない。 たとえば、 ・AIsがほとんど改善(mitigative) 障害の再発可能性を最⼩化するために、予防処置項⽬と修正を含めるべき 予防処置的な アクションの⼀つは、「⼈間がエラーを起こしにくくする」になっている。 ⼀般的に、 Key details omitted Key action item characteristics missing
  7. 7. ⼈間の⾏動を変更させることは⾃動化されたシステムやプロセスを変更するより信頼がお けないものである Dan Milsteinが語ったように 我々は皆、今⽇と同じくらいおろかである将来を想像しよ う。 ・優先度がすべて同じになっているため、最初にどれに着⼿すべきか決定できない。 ・2 つのアクションで、改善する、より良くするといった曖昧な⽤語を⽤いている これらの ⽤語は曖昧で、会社の余地がある。 不明瞭な⽤語は計測したり理解したりのを困難にす る ・不具合表に結び付いているアクションが⼀つしか無い。 フォーマルな管理システ ムがないと、AIsはしばしば忘れられ、障害につながってしまう。 Ben Treynor Sloss⽈く 顧客のために、継続するアクションの記載がないポストモーテムがあってはいけない。 顧客に影響のあった障害のポストモーテムはすべてP1のバグが含んでいなければいけな い 例外はほとんない。 すべてのポストモーテムは 責任追及的な物語に陥るリスクをもっています。 この例でいえば、、、 ・Things that went poorly 結果をチーム全体ではなく、2⼈のメンバーを名指しにしてい る ・Action items sydneythree@がプレッシャーの標的になっている ・Root causes and trigger dylanfour@が障害の責任をになっている。 ポストモーテムで個⼈を特定することはよいアイデアかもしれないが、 メンバーが公に 辱められることをきらって、リスク回避志向になるかもしれない。 再発防⽌と予防に重 要な事実を隠蔽するように動機付けられてしまうかもしれない。 ポストモーテムは個⼈の判断や主観的な表現がない事実に基づいた⼯芸品であるべき。 個⼈の判断や主観的な表現は It should consider multiple perspectives and be respectful of others. この例では、 いくつかの望ましくない表現がある ・Root causes and trigger careless ignoranceといった余計な表現 Counterproductive finger pointing Animated language
  8. 8. ・Things that went poorly 「これは⾺⿅げている」といった⽣き⽣きとした表現 ・Where we got lucky 「信じられない!」といった感嘆符のりよう ⽣き⽣きとした表現やドラマテックな表現は 主題部分から⽬をそらせさせ、⼼理的安全 性を浸⾷する。 ドキュメントの正当性を主張するためには 検証可能なデータを提出すべき オーナーシップを宣⾔することで説明責任が⽣じ、それがアクションにつながる、。 この例ではいくつかのオーナーシップの⽋落が⾒受けられる ・4⼈のオーナーがいるが、理想的には、⼀⼈にすべき。 その⼈が、ポストモーテムやフ ォローアップや、遂⾏に責任をもつべき。 ・AIsにほとんど、もしくはまったくオーナーシップがない。 担当者不在のAIは解決され る⾒込みが低い オーナーは⼀⼈で、協⼒者が複数いるのが望ましい。 この例では、チームメンバーにだけポストモーテムが共有されていた。 原則的には、全 社員がアクセス可能であるべき。 顧客にすら共有することが推奨である。 ポストモーテムの価値は、それによって⽣み出される学習(機会)に⽐例する 過去のインシデントがより多くの⼈が学べば、 再発することは減るはず。 よく考えられ、正直なポストモーテムは信頼回復のツールとなる。 経験やコンフォート が成⻑すれば、顧客は⾮⼈間にまで広がるはず。 ポストモーテム⽂化が成熟すれば、機会が読むことができるうような メタデータを付与 して、より広い範囲で分析が可能となる。 ポストモーテムの公表は事後4ヶ⽉であった もしこの件が再発しなかったとすれば(実際 には起こってしまったが)、 チームメンバーはポストモーテムの詳細情報を失念してい たかもしれない。 Missing ownership Limited audience Delayed publication

×