つけることで定期的にトラッキングしています。障害対応への心構えこれまで、障害が発生したときの流れを説明しました。これらを実際にやるには知識だけではなく、経験が必要です。(残念ながら)いくつか障害対応を経験してきた中で、大事だと思うことをいくつか紹介します。落ち着くこれが一番大事です。起きてしまったことは仕方がありません。上記で述べたようなやるべきことを確実にやるべきです。障害対応はリアルタイムに影響が発生していることもあり、プレッシャーを感じてしまうひとも少なくないと思います。(もちろん私もそうでした。発生したりと、非常に難易度の高い仕事です。いった仕事を確実にこなすためにも、落ち着くことが何より大事です。(楽観視するという意味ではなく、冷静であるという意味です。)役割分担する最低限、以下は分けたほうが良いでしょう。現場を指揮統率するひと障害内容を報告するひと復旧・原因究明をするひとポストモーテム(後述)を書くひと前述したように、障害発生時に(時間のプレッシャーもある中)難しい障害に対処するには集中することが何より大事です。障害発生時に役割分担をする様子ある日の障害対応では、上記のように役割分担を行うことで非常にスムーズに解決を行うことができました。役割を分担し、それぞれリードを行うひとを決めることで、それぞれの関心事項に関して周囲のひとが協力して解決を行うことができました。現場を指揮統率するひとは主に判断と担当へのアサインを行います。システムを熟知していて、ステークホルダーをよく知っているひとが適当でしょう。よって報告を行います。ビジネス・プロダクトの責任者が適当かもしれません。ポストモーテムを書くひとは、現場を指揮統率するひとが兼ねてもいいでしょう。用いてこまめに状況を書き込んでいます。残すようにしています。原因究明や再発防止のプロセスでは絶対に特定個人の振る舞いに注視しないようにします。「起きた問題」に対して、チーム全員で解決に向かって建設的に向き合いましょう。ポストモーテムここまで、障害発生時にどのように考え、動くべきかを述べてきました。次に、障害が収束したあと、その障害を2度と発生しないためのポストモーテムとその活用方法について紹介します。ポストモーテムとはポストモーテムとは、障害発生の経緯をまとめ、「失敗から学ぶ」ための取り組みです。やっていない方は今すぐできるプラクティスとしてオススメします。ポストモーテムを理解しています。いつ書くのがベストかいつでもいいのですが、私は「暫定対応」フェーズのあと、がベストだと考えています。(よくできたテンプレートであれど)ひと段落したあとから作成するのは面倒だからです。これは直接の原因究明を行うエンジニアより、別のひとが作成したほうが良いと感じています。役割分担として最低3つあげましたが、ポストモーテムを書くひとを分けてもいいですし、個人的には指揮統率を取るひとが書いてもいいと思っています。更新すると非常に楽です。記載して、担当者をアサインしましょう。決め、担当をアサインします。これが行われなければ何も意味がありません。行われているかを確認しましょう。して独立に扱った方がいいかもしれません。項目が非常に大切だと感じています。体現していると思います。障害を悪いことと捉えず、学びとして前向きに捉えて、チームを成長させることができる重要な観点です。入ったタイミングで過去のポストモーテムの読書会をはじめてみました。有益な取り組みですのでオススメします。ポストモーテム読書会初回を終えての所感ポストモーテム読書会を行うことによって、以下のような有益な点があります。SLOさて、障害発生フローによると障害の判断基準が記載されていると述べました。実際の現場では起きた事象に対して個別に緊急性を判断して対応を行うと思います。それとは別に、より精密に、システマチックに判断できる基準があるとより便利でしょう。起きた際に、ポストモーテムを書くか、と思った時に、ふと「どういう基準でポストモーテムを書くのだろう」と考えたのがきっかけでした。あるべきだと思います。関しての詳細の説明は省きます)しかしそのためには、以下のようなことを考慮する必要があります。策定と運用についてはまた別途記事を書きたいと思いますが、障害を判断する基準としては有益かもしれません。最後に、障害を予防する仕組みについて簡単に紹介します。なんもしてないのに治った人間はスケールしません。行ってない限り、障害対応をいつでも行うことは不可能です。変更)によって起きますが、一方でそれ以外の予期せぬ原因によっても発生します。しても可用性に影響しないような設計をし、復旧時には自動的に復旧することが望ましいです。行うことになると思います。協力してシステムの信頼性を保っています。いろいろなチームからリクエストが届いています。連携できるとても良い仕組みだと感じています。呼ばれる独自の仕組みを@ujihisaが導入しました。いう外部サービスを利用した仕組みも存在します。これらによって、アプリケーション単位ではなく、機能のレベルでリリース(公開・非公開)をコントロールすることができています。実際にオン・オフを実施しており、実験的な機能、新機能をこっそりデプロイしておいて、任意のタイミングで実行・解除を行っています。