Masteries

技術的なことや仕事に関することを書いていきます.

障害対応五訓

※このエントリは, 技術書典6で頒布された「Hatena Tech Book」に寄稿した, 「障害対応五訓」をブログに掲載したものです.

papix.hatenablog.com

Webサービスを運用していると,さまざまな障害と出会います.当然,そんな障害とは一切出会わずに済むのが一番ではあるのですが…….とはいえ,どうしても立ち向かわなければならないときがあります. これまで5年ほど,業務としてWebサービスの開発や運用に携わってきて,さまざまな障害と直面し,たくさんの成功や失敗を経験してきました. その中で,障害に立ち向かう際に求められる振る舞いや,解決に至るために必要なアクションについて,いくつかの気付きを得ることができました. そのような知見を,「障害対応五訓」としてまとめてみたので,紹介します.

障害とは非日常である

鳴り響くアラート,騒がしくなるオフィス,ターミナルには大量の文字が流れ,エンジニアの額には汗が浮かぶ……. 障害対応は,日々Webサービスを開発し運用している人たちにとっては切っても切り離せない存在ではありますが,日常の開発とは異なり,予測不可能で,臨機応変な対応が求められ,それゆえに緊張感が高まる状況と言えます.

自分の場合,障害が起きるとどうしても慌ててしまいます.自分が心をこめて開発しているプロダクトを早く復帰させて,利用するユーザーへの影響を最小限に抑えたい. そしてその焦りは,得てして障害対応の場面において本来は不要なはずの,過剰な高揚感に繋がりかねません. そんな焦り,異様な高揚感といった感情をきっかけとして,障害対応に取り組む中でオペレーションミスをしてしまったり,コミュニケーションが粗雑になって雰囲気が悪くなってしまったり,伝えるべき情報が然るべき人に伝わらなかったりといった二次被害が発生することもあります.

このような二次被害を防ぐには,障害に陥ったプロダクトの状況を正しく理解し,必要な手を打ち,チームメンバーがそれぞれの役割を果たして冷静に行動することが重要です.そのためにも,会社やチームによって障害対応時のマニュアルやワークフローを定め,それに則って行動することが重要です.特に,障害が発生したと伝える必要がある人たち(ステークホルダー)や,障害対応時によく陥る落とし穴などの情報がまとまっていると,慌てがちな障害対応の初動において,非常に便利な道標となります.

加えて,当然ではありますが平常心を持って障害に望むのも重要です.とはいえ先にも述べたように,障害は予測不可能で突然訪れるので,何も準備のない状態で完全な平常心を保つのは難しいところがあります.

そこで,せめて「障害対応の時,平常心を保てなくても,ここだけは抑えておきたい」というポイントを「障害対応五訓」として選び,会社やチームの定めるマニュアルやワークフローとは別に、個人としての心がけとして思い出せるようにしました.

障害対応五訓

心は熱く,頭は冷静に

障害が起きたとき,自分は慌てがちであると同時に,心が熱くなるタイプの人間です.そういった感情が,障害の解決へ至るまでの力に繋がる部分もあるのですが,とはいえ頭まで熱くなると,視野が狭くなり,最適な選択肢や情報を見逃してしまいがちです. 心は熱く煮えたぎらせて力に変えつつ,一方で頭は冷静になって,起きている出来事に対して視野を広く保つことが大事だと思いました.

まずは深呼吸,そして役割分担から

障害が発生すると,急激に気持ちが高ぶります.特に,自分のコードやオペレーションが原因で障害が発生した場合などは,「早く回復しないと!」という気持ちや,「やってしまった……!」という気持ちがごちゃ混ぜになって,冷静に振る舞うこと難しい場合があります. 結果として,そのまま勢いでなし崩し的に障害対応に向かってしまいがちです.

そうならないように,障害が起きたらまずは深呼吸をして,一呼吸置くことが大事だと思いました.高ぶった感情とそれに伴って熱くなっている頭を,いったん通常の状態に戻すイメージです. また可能なら,チームみんなでいったん深呼吸してリズムを合わせ,会社やチームで定めたマニュアルなどを参照しながら,「役割分担」の確認から障害対応を始めていくのが良いと思います.

チームで障害に立ち向かうときは,「考えるリソース」を原因の調査や対応に割けるように,それ以外の部分はなるべく考えなくても進むように準備することが大事です.対応の指揮者は誰が担うのか,記録を残すのは誰か,実際にオペレーションをするのは誰か,プロデューサー・ディレクターや営業といった他職種のメンバーとコミュニケーションを取るのは誰か……. 最初に役割分担を丁寧に確認することで,障害対応の途中に「このタスクは誰がやる?」で右往左往する事態を大幅に減らせるはずです.

プランB,プランCまで考える

障害に立ち向かっているとき,特に原因が明らかでない場合には,計測と調査,原因の推測を繰り返し,その結果見つかった対応策に片っ端から取り組んでみて,その結果どれかが当たって沈静化する……,というパターンが多いように思います. とはいえ,時と場合によっては1日で解決せず,数日〜数週間の規模で障害が続くこともあり得ます.

障害対応が長期化したときには,サービスへの影響を考慮しつつ,「現在の段階ではここまで」といった最低限のラインを定め,そこを目指して行動するという意思決定も求められます. 目先の問題だけに捕らわれず,それが効かなかった場合の次の一手や,サービスとして必ず死守したいラインについても,平行して考慮していくことが大事だと思いました.

休憩するのも仕事のうち

障害が長期化したときはもちろんのこと,すぐに解決できることが見込めるときも,「動く人」と「休む人」をきちんとアサインするのは大事だと思いました. 長期化したときには,きちんと稼働と休暇の管理をしないと最終的には誰も動けなくなるという事態に陥るかもしれません.また障害が幸いにも長期化しなかった場合でも,障害に立ち向かった人はどうしても消耗しがちです. そのため,例えば障害の恒久的な対策や,影響範囲の調査を担えるメンバーを温存しておく(そのため障害対応中にしっかり休んでおいてもらう)ことは重要です.

仲間が苦労して障害に立ち向かっている中で休むのは罪悪感がかなりありますが,とはいえ「休憩するのも仕事のうち」です.その休憩が,障害対応の次の一手に必要不可欠と思って,しっかり休むようにしたいものです.

広く意見を募り,謙虚に受け止め,解決への糸口を掴む

一緒に障害に立ち向かう仲間は,それぞれ違う経験やスキルを持っています.さらに,はてなにはさまざまな経験・スキルを積んだエンジニアが他チームにもたくさんいます. 障害に立ち向かうにあたっては,その障害をさまざまな視点で眺め,解決のためのアクションを見つけることが重要です.そのため,仲間の力をうまく引き出すことは,障害を解決する近道だと言えます.

障害に対応しているとき,普段以上の情報が脳内を,チームを,そして社内を駆け巡ります.そういうときに,仲間の意見を受け取ったり引き出したりするアクションへの優先順序が下がったり,あるいは仲間が出してくれた意見を受け取る余裕がなくなってしまうことがあるように思います.障害対応のときはもちろんのこと,常日頃から謙虚な気持ちを忘れず,仲間の意見をうまく引き出してインプットし,視点を増やして障害解決へ至るきっかけを探していくことが大事だと思いました.

最後に

実際に障害へ対応する中で自分なりに気付いた,障害対応における大事なことを「障害対応五訓」として紹介しました. この五訓を一言でまとめると,なんとなく「まずは落ち着く」という言葉に集約される気がします. 障害対応の中で落ち着くためにどうするか? そして落ち着いた上でどういうアクションするか? ということがまとまっているように思います.

最初にも述べたように,障害は遭遇しないに越したことはありません.とはいえ,突然皆さんの前に立ちはだかるものなのです. そういった事態に備えて,皆さんも「ここだけは押さえておきたいポイント」を常日頃から考えて,備えておくのはいかがでしょうか.