4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

commmuneAdvent Calendar 2023

Day 1

障害対応に役立つであろう5つのTips

Last updated at Posted at 2023-11-30

初めに

この記事は commmune Advent Calendar 2023 の1日目として投稿されました。

障害対応とは

Webアプリ開発の舞台裏において、我々エンジニアにとって避けては通れない課題が障害対応です。
最高のアプリケーションでも、障害が発生し続けると、そのアプリ自体の印象が大きく損なわれてしまいます。従って、障害発生時のスピーディーな対応が、Webアプリの品質向上に直結していると言えるでしょう。

今回、私がQAエンジニアとして長年の経験から得た知見を基に、障害対応時の有益なTipsをまとめてみました。なお、本記事では障害対応の大枠である「障害対応時のワークフロー」や「原因解析法」などについては取り扱いません。その代わりに、日常業務で実践可能なアプローチや工夫に焦点を当て、障害対応の効果的な戦略について考察してみました。

障害対応に役立つであろう5つのTips

テキストベースの会話を心がける

障害発生時の多くは、関係チームが業務中もしくは休暇中なので各チーム一斉に障害対応が始まることはありません。そのため、障害に気づいたチームから障害対応に加わっていきます
障害対応に加わったチームがまず初めにすることは状況の把握ですが、それまでの対応状況を口頭で会話していると次に来るチーム次に来るチームに対して逐次口頭説明が必要になってきます

障害対応は1分1秒を争う現場なのでビジネスサイド、経営サイド、プロダクトサイドが状況を把握しようと必死なのはわかりますが口頭説明が間に挟まることで説明する時間(= 障害対応に充てられない時間)が生じます。これらを避けるためにテキストベースの会話を基準にすることで、後から加わったチームはテキストを確認によって状況把握とネクストアクションを確認することができます。

また、このテキストベース基準は障害が始まった時に決めるのではなく事前のチーム間の認識共有が必要です。そのため、障害発生する前の準備段階でどのテキストに対してどのように記載するかの合意形成が必要です。

タイムラインを引く

障害が迅速に復旧できる場合は、タイムラインを詳細に引く必要は少ないかもしれませんが、長期にわたる障害対応が見込まれる場合は、タイムラインを明確に設定することが重要です。タイムラインを引くことで各チームが何時までに何をやるべきなのかが明確になります。障害対応時には集中して作業することが多いので「いつまで」の部分がとても大事になってきます。

タイムラインを引く時は以下の項目を入れるとス作成がムーズにいきやすいです。

  • 各チームのネクストアクション
  • 情報共有の時間
    • 一次情報共有の時間
    • 二次情報共有の時間
  • デッドライン
  • 障害復旧のための準備時間

これらの項目を含む明確なタイムラインは、各関係者が共通の目標に向かって協力しやすくなります。

情報を共有する時間を予め設ける

上の項目にも記載しましたが障害対応において「情報共有の時間」が大事だと私は考えています
いざ障害対応に取り掛かると自チーム以外の状況把握が疎かになってしまいます。この時、例えばAチームにとっては不必要な情報でもBチームにとっては大事な情報であることが多々あります。

他の具体的な例として挙げますと、
ビジネスサイドは完全な復旧ではなく一時復旧を優先して欲しいと考えている。対してプロダクトサイドは完全な復旧を目指している等の認識齟齬により障害対応が遅れるケース等もあります。

このように、それぞれのチームが円滑に業務を進めるためにも一度障害対応の時間をストップさせて情報共有することが大事です。

事実と推測を分ける

障害報告書を書く際にも大事なことですが障害対応時にも大事なことです。
特にネクストアクションを決める際や、各チームとの情報共有する際には以下のことに気をつけましょう。

  1. 事実と推測を混ぜて会話しない
  2. 相手の発言が事実か推測かが曖昧な場合は都度確認する
  3. 推測は悪いことではない

こう書いてしまうと「推測すること自体が駄目」だと捉えられる可能性があるので追記しました。推測することはむしろ大切なことです。障害の原因を突き止めるときは 「ここに原因があるかも」の推測の繰り返しです。

そのため、推測することは大事ですが他人に伝えるときは何が事実で何が推測なのかがわかるように伝える必要があります。

何を実施するのかを予め決めておく

障害発生時にこのようなポイントを守って行動することは難しいです。
そのため、予め何をするのかを決めておきできるのであればワークフローに組み込んでおく必要があります。私が従事するチームでは、障害対応をより早く進めるために障害発生時に以下のようなワークフローを自動で流すようにしています。

image.png

終わり

障害対応は心身的なダメージを受ける反面、乗り切ることでプロダクトとしてもチームとしても成長できます。このTipsがエンジニアの助力になれれば幸いです。

4
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?