1
0

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.

「インシデントにどう対応してきたか?みんなで学ぶポストモーテム Lunch LT」参加レポート #LT_findy

Posted at

2月9日、「インシデントにどう対応してきたか?みんなで学ぶポストモーテム Lunch LT」に参加しました。

LT①『ポストモーテムはじめました』

スピーカーは株式会社スリーシェイク @nwiizoさん。

まずはポストモーテムという概念そのものに関する説明から。
SREにおいては障害や失敗が発生したら、解決したらOKではない。失敗から学び、同じ過ちを繰り返さないためポストモーテムの実施が重要とのことです。
ポストモーテムはSREの文脈で語られることが多いキーワードですが、約10年前からあるもの。SREにおいては、さまざまな活動の中のひとつに組み込まれているそうです(つまり、これをやっていればSREとしてOKというものではなく、多角的な活動が必要)。

また、ポストモーテムは特定の型が決まっているものではなく、現場によって適切な形は異なりますが、以下については必須と考えているとのことです。

  • 明確さ
    • 読み手が主題を間違えないドキュメント
  • 具体的アクションアイテム
    • 組織でどのように対応するか決めておく
  • 非難を行わない
    • 心理的な安全性を確保する
    • 人ではなくプロセスに焦点を置く
  • 周辺への影響度の深さ
    • 運用者として誇れる仕事を
    • 解決に至るまでに使われたソフトウェアなども記載しておくとより良いポストモーテムになる
  • 即時性と簡潔さ
    • リアルタイム性を大事にする
    • 担当者間でタイムラインでコミュニケーションをとっているとGood

お勧めのドキュメントとして『SRE WEEKLY』も挙げられていました。メール、またはRSSで購読できるようなので、SREに興味がある人は読んでみるといいのではないでしょうか。

LT②『ポストモーテム運用を支える文化と技術』

スピーカーは株式会社リクルート @chaspyさん。

障害発生後にポストモーテムを作る文化は現状でできているそうで、日常的にどのように実践しているのか話していただきました。

障害が誰かひとりのせいにならないように工夫していて、複数人でのレビューなどで共同で作業するよう心がけているとのことです。
また、オンボーディングで過去に作ったポストモーテムの読書会を開くことで、過去の知見を活かしているようです。
ポストモーテムは日々増えていくので全部読むのは現実的に不可能ということで、「おすすめ」ラベルをつけて読む対象を絞り込む工夫もされているそうです。

また、ポストモーテムを文化として定着させるために、最初はSREが主体で(ポストモーテムを書くよう)言い続ける、(自らポストモーテムを)書き続ける、ブログを公開するなどが大事とのことです。

「重要な障害を防ぐ」、「適切なリスクを取る」、「念の為の確認を簡単に行う」といったことも重視していて、そのために以下の取組を行っているそうです。

  • 負荷テスト
  • Canary Release
  • E2E Test Automation
  • データベースリストア

LT③『All for One なポストモーテム運用と工夫』

スピーカーは株式会社メルカリ @Fumiya_Kumeさん。

メルカリさんでは2017年からポストモーテムを運用を開始し、現在はSREだけでなくあらゆる職種で運用しているとのことです。
インシデントの定義を「お客様に影響を与える予期せぬサービスの中断や品質の低下」としているため、SRE以外にもポストモーテムが定着しているとのこと。
組織形態の変化に対応してSlackコマンド、Botの導入、Blameless(これは初耳だったので後で調べてみたいです)の導入など、日々変化を続けていくことが重要という話が印象に残りました。

LT④『Postmortem as a textbook』

スピーカーはLINE株式会社 @maruloopさん。

ポストモーテムから他チームが学びを得るためには、以下が重要というお話でした。

  • 読むだけで、システムの概要が理解できる
  • 問題と解決策の間に飛躍がない
    • コンテキストを知らない人が対応策を読んでも疑問を持たれないような内容にする

共有会議の前段階として以下の取組を行い、結果的に品質も向上し、共有会議自体の時短にもなったとのことです。

  • 全体共有の前に執筆のための会議を開く
  • ファシリテートはSREが行う
  • SREが担当する他チームも呼ぶ

最後に

どのLTも共通して「人ではなく問題自体に注目する」ための取り組みをされている印象を持ちました。
障害対応と聞くとどうしてもネガティブなイメージが先行しがちですが、個人が責められる心配がない環境で、障害対応を通じて新しい学びを得たり、よりよいプロダクトを作るためのチームが作れると考えると、そんなに悪いものでもないような気がしてきますね。
弊社もポストモーテムは手探りながらも導入していますが、SREに限らず全チームで障害に前向きに取り組める文化を育てていきたいものです。

また、LTで紹介されていた技術も「魔法のように問題解決してくれる最新の○○!」ではなく、昔から語られている基礎的なものばかりでした。安定したプロダクトを作るには基礎を疎かにせず、地道な積み重ねしかないのだなと感じました。

1
0
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
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?