移転しました。

約3秒後に自動的にリダイレクトします。

Datadog Incidents を使ってみて雑感

こんにちわ、冒頭の書き出しに何をかこうか考えるのが一番時間がかる、id:gaoohです。

今回 Datadog Incidents を使ってみて思いのほかよかったのでその感想をまとめます。

そもそも、みなさん何でインシデント管理をしてますか。

よくあるパターンはタスク管理はきちんとされているけど、突発的なインシデント対応は管理されていない。 クライアントやユーザに報告のために履歴は必要に応じて記憶ベースでSlackをおってあとでまとめる。 その場でおもいつた改善策はタスク積んでおくけど、喉元過ぎれば忘れられ、棚卸しの際に「これなんのことだっけ。。。」 みたいなことになりがちではないでしょうか。

私はごめん、めっちゃよくやってた！

もちろんやることたくさんあるプロダクト開発においてすべて綺麗にできないのも事実で、実際やりきれないこともあります。 ただし中長期を考えるとこれらをおざなりにしてくことは大きな損失になりますし、できる基盤や組織をつくっていかねばなりません。

なので、現状VideoTouchではインシデント管理を monday.com でおこない、タスク管理と紐付けています。

インシデントの中身はちょっと隠していますが、以下のような感じでまとめてます。 数が多いのはなやみではありますが、だからこそ手を打っていかねばならないのです！！誰か助けて！

工夫している点としては紐付くタスクも「暫定対応」「恒久対応」「再発防止策」と分類し、きちんと最後の再発防止策まで手をつけられてるかぱっと見でわかるようにしています。また何が起因で立てられたタスクなのかを紐付けるようにしてます。

なかなか再発防止策まで手が回らないとい、とりあえずの絆創膏対応でおわってしまうのも実情なくはないですが、その実情も見える化できるメリットもあります。

また中長期での改善はなかなかすすめれらないので、これをベースの履歴として残して四半期ベースで振り返るようにしています。

現状の運用の課題

この運用によって最低限インシデント管理できているのですが、発生時に時系列でなにをしたのかの記録方法が人によってまちまちであとから振り返りにくいという課題がありました。

何をしたのかはリアルタイムではなかなか残せないので、後日別途notionでまとめています。 このあたりはユーザへの告知やビジネスサイドとの影響範囲の説明のためにも必要ですし、同日対応に参加できなかったメンバーへの共有も含めて、ある程度最初の一次対応がおわったらまとめるようにしています。

その際、何を残すのかがあいまいなので人によって概要はのこっているんだけど、ログやデータがのこっていないこともありました。 またデータも見やすさ重視で毎回スクショにとってはりつけたりしていて手間もかかってしまっていました。 もちろん何を残すのかを定義するという対策もありますが、そんな中お試しでDatadog Incidentsをつかってみたら課題を解決できそうで、かついろいろメリットが大きそうだったのでまとめてみました

Datadog Incidentsを使って感じたメリット

インシデント管理として残す情報のフォーマット化

「なにがおきたか」「インパクトは（影響範囲）」「なぜおきたか」 これがデフォルトのフォームとして用意されています。また追加でフィールドは足したり削ったりもできます

notion でもテンプレート機能を使えばできなくはないですが、履歴や更新タイミングなどふくめてすべて残るのは強い。

インシデント発生時のモニタリング情報を簡単にまとめられる

なにか障害が発生したときにDatadog上の情報をみて状況を把握していくということをやるわけですが、「どこをどうみてどう判断したか？」 というのは正しく切り分けをする際に非常に大事ですし、ここは人によって知識差がでやすいのでなるべくチームに共有していうべき情報だと思います。

それが正しく行えないとわかりやすくインフラ周りが属人化していきます。

かといってこの辺は職人芸的な部分も含まれていて、一緒にハイスキルの人とアラート対応をして師弟関係的に伝授していく部分も多いです。

その間をなんとか埋めていきたいと考えたときに、誰もまだ対応していない障害に対しての瞬発力的なものは、実際の対応を経験して培いながら、既に一度対応したものは誰でも対応できる状況にするというのが一番の近道です。 一度やったことに関したは先駆者たちが作った道があるので、その道にそって調べていけばいいことも多いわけですし。

なので「どこをどうみてどう判断したか？」は過去を先駆者たちの動きを学ぶためにも非常に大事な資産なのですが、障害対応をしながら、それらを残すためにはなかなか難しい。かといってあとから思い出して整理するのは腰が重いですしね。

これらの課題に対して、Datadog上でサーバのモニタリングをしている場合、そのモニタリング情報をインシデントのタイムラインに追加するのことがさくっとできちゃいます。

よい！

表示しているグラフからワンクリックでできるので手間がないため、対応しながら追加していくのも慣れてしまえばそこまで苦ではないはず！ ただ追加するのが苦でなかったとしても、追加するのを忘れるのはありえるので、そのあたりは場数を踏みながら慣れるしかないでしょう。

Slack 連携

インシデントについて特定のチャンネルに通知するのはもちろん、インシデントごとにチャンネルをわけて対応することも可能です。 今のViibarの規模だと1つのチャンネルで完結しちゃってますがサービスの規模が大きくなったり、チームの規模が大きくなった際でも便利そう

まとめ

まだ使い切れていない機能も多いですし、試しにやってみたところで本格的な活用はこれからですが、大枠よさそうなので今後活用してければとおもってます。

インシデント管理は胃が痛くなりますが、サービスが成長していく中でうまれるプロダクトの技術的な課題や運用課題を中長期的な目線でみながらあーでもないこーでもないと考えて解決していくことって独特の楽しさですよね！

ではでは！