チーム状態をスムーズに変えて障害対応のコストと精神的負荷を抑える

こんにちは。 @at_grandpa です。普段はバッチを書いたりメンテナンスをしています。

今回は、先日起きた障害対応の時、チームの状態をスムーズに変えることで対応コストと精神的負荷を抑えられた、ということを書きます。

 

目次

障害発生

先日の朝に「レポートの数値がおかしい」という連絡がきて確認したところ、とあることが原因で、バッチの自動実行が約半日行われていないことがわかりました。

 

f:id:at_grandpa:20170713114354p:plain:w400

 

普段の対応

普段の対応は以下のような形です。

  1. エラー発生をSlackの全体チャンネルで報告
  2. バッチ系チャンネルにて、考えや現状を垂れ流す
  3. わからないことがあれば有識者にメンションを飛ばす
  4. 実際に叩いたコマンドをどんどんSlackに書き込む
  5. 対応完了を全体チャンネルで報告
  6. チケットにまとめる

小規模なエラーの場合は上記の対応で事足ります。この方法のメリットは以下です。

  • 対応は一人ででき、他のメンバーのコストが発生しない
  • Slackに垂れ流すことでプチレビューの役割を果たす
    • 精神的負荷が多少軽減される
  • Slackにコマンドの履歴が残る

しかし、しばらく運用していると、デメリットが大きくなってきました。

  • 「一番知っている人はat_grandpa」という理由からか、指摘されることが少なくなった
  • 上記が理由で「孤独感」が強くなった
  • 孤独感から「この対応で大丈夫か?」という気持ちが生まれ、精神的負荷が増える
  • 対応方法が伝授されない
    • 記録はあるが、他のメンバーが同じ対応をできるかと問われるとなかなか難しそう
    • 実践で行わないと自信を持って対応することは難しい

信頼されることは嬉しいですが、この信頼はチームを腐敗させます。今までは「対応すること」を優先で行ってきましたが、実際はチームの動きを鈍らせてしまう原因になっているのだと気付きました。この点は反省すべき点です。(自分の共有方法やドキュメント記述方法にも問題があります。それはまた別の問題として認識します。)

しかし今回、新しいアプローチで障害対応を行ったところ、上記の懸念点も解決し、かつスムーズに対応が行えたので、ブログに記録したいと考えました。

 

今回の対応

今回の対応の流れは以下です。

  1. 原因究明と現状把握
  2. 関係者が会議室に集まる
  3. 対応用Slackチャンネルを開設
  4. ペアワークで実対応
  5. 落ち着いたら自席&Slackコミュニケーションへ移る
  6. 対応完了の確認と報告・チケットまとめ

一つずつ見ていきます。

原因究明と現状把握

あるバッチがエラーを吐くことはたまにあるのですが、今回は約半日動いていません。普段と異なる時間帯に数十のバッチを手動で叩かなければなりません。普段と規模が違います。

関係者が会議室に集まる

流石にひとりだと荷が重いと判断し、バッチ周りに触れたことのある新卒2年目の @saxsir256(以下@saxsir)と新卒1年目の@__himu__(以下@himu)にリカバリタスクをお願いしました。と、そこで以下の提案がきます。

f:id:at_grandpa:20170713085202p:plain

これはなるほどと思いました。関係者がガッと会議室に集まることで、以下のメリットがあります。

  • メイン対応者が明確になる
    • メインの対応者が明確でないと、チーム全体が「何かしないといけないのかな。。。」と不安定な状態になってしまいます。これを阻止するためにも「今回はこの3人で対応します」と名言できたのは良かったです
  • 初動が重要な場面で対面コミュニケーションできる
    • Slackは便利ですが、対面コミュニケーションの速度には敵いません
    • 初動の場面でスピーディに共有・方針決定できたのは大きかったです
  • 精神的負荷の軽減
    • 障害対応の初動は何かと不安が大きいですが、対面でのやり取りは精神的負荷をかなり抑えます

実際、この判断はとても良く、自分も把握しきれていないバッチを@himuに解読してもらいつつ、@saxsirと共にホワイトボードを用いて対応スケジュールを組み立てました。わからないことはすぐに共有、わかる人とペアワーク、という軽快な動きが可能でした。

対応用Slackチャンネルを開設

対応用Slackチャンネルの開設は、社内でも一時期話題になっていましたが、実際にメインの運用にはなっていませんでした。自分ひとりの対応の時に、試しに開設したりしていましたが、メモ程度の役割にしかなっていませんでした。しかし今回は3人がメイン対応者です。対面コミュニケーションのスピードは良いですが、記録を残すことも重要なので、とにかく、

  • 実行したコマンドとその結果
  • 現在何をしているかを投稿(他の外部メンバー向け)

を書いていきました。「このチャンネルで対応実況しています」ということを全体チャンネルで発言することで、続々と覗きにくる方が増え、メモ&外部共有が両立できたのは大きかったです。

ペアワークで実対応

先程も書きましたが、会議室に集まることでペアワークが可能となり、精神的負荷を抑えることができました。かつ、対応のちょっとしたノウハウなども詳細に伝えることができたり、実際にコマンドを叩く経験ができるため、今後の対応への自信につながるというメリットもあります。実際、自分でも詳細を知らないバッチを@saxsirと@himuが解読してくれ、それをSlackに残してくれているのでとても助かりました。

落ち着いたら自席&Slackコミュニケーションへ移る

バッチを順に叩いていきDBの状態を確認、次のバッチへ・・・という作業を続けていくと、「依存関係はもう無いし、後は順に叩いていくだけ」という場面になりました。この段階で会議室に集まっているメリットはもうあまりないと判断し、「自席に戻って他のタスクを行いつつ、Slackにて共有」という形に移りました。このようにチーム状態を変えたおかげで、午後からは他タスクに移ることができましたし、ちゃんとSlack上での確認も行え、無事対応を終えることができました。

対応完了の確認と報告・チケットまとめ

対応完了を全体チャンネルに報告し、チケットにまとめます。チケットへのまとめは、Slackの対応用チャンネルの重要部分のリンクを貼るだけです。まとめ直すのは結構コストが高いので、実対応が記録できる対応用チャンネルは便利だなと思いました。

 

まとめ

今回の対応は、以下の点がよかったと思います。

  • メイン対応者を明確にすることで、他メンバーのコストを抑えられた
  • 対応用Slackチャンネルのおかげで、記録と共有を両立できた
  • 障害対応の初動で対面コミュニケーションを取れた
    • 精神的負荷の一番大きなフェーズで負荷を抑えることができた
    • 方針決定までの速さが今までよりも早かった
    • 対応メンバー全員がバッチ周りに詳しくなった
  • 落ち着いたら自席&Slackコミュニケーションに移った
    • ずっと1日中対応しているのではなく、他のタスクにも移行できた
    • 結果、対応に対する時間を削減できた

個人的に学びがあったのは、対応の状況によって 会議室&対面 → 自席&Slack に移行したことで、対応の総コストと精神的負荷を抑えることができたという点です。

ともあれ、「何かあったら会議室」というのもおかしな話なので、臨機応変に活用していきたいと思います。

今回、「障害対応にはフェーズがある」ということと「新しい障害対応の方法」に気づけたのは非常に価値がありました。この経験を踏まえ、今後に活かしたいと思います。

 


 

VOYAGE GROUP では最近Podcastを始めました。 → Ajitofm

社内バー AJITO での語らいを収録したポッドキャストです。技術談義で盛り上がったり、もしかたら今後、障害対応の裏話なども聞けるかもしれません。