クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

週刊ポストモーテム継続への道のり

f:id:bayashi_ok:20210318092810p:plain

こんにちは、SREチームの @bayashi_ok です。

今回はクラウドワークスで週1回ペースで実施している「週刊ポストモーテム」の取り組みをご紹介していきます。

ポストモーテムとは

まずポストモーテムという単語について少し説明します。

ポストモーテムの意味は各分野でも変わっており、医学の世界では「検死」、プロジェクトマネジメントの世界では「事後検証」などの意味を指します。

SREの文脈では主に、

  • 障害などが発生した際の影響
  • そのとき行われたアクション
  • 障害発生の根本原因
  • 再発防止のためのアクション

などを記録するために書かれるもので、いわゆる「障害報告書」のようなものになります。

ただ、記録としての報告書というだけではなく、組織的な学びのために蓄積していくものだということです。

・SRE公式本(WEB無料公開版)

https://landing.google.com/sre/sre-book/chapters/postmortem-culture/

・その他参考記事

https://tech.mti.co.jp/entry/2017/11/25/000316

https://note.com/campfire_dev/n/n2a46e3832207

週刊ポストモーテムとは

週刊ポストモーテムとはこれを毎週継続的に実施して行く取り組みです。

始まりは2019年2月で、障害が発生したときに、どんな情報から・どんな判断をしているのかというのを共有する場として設けられ、実際のアラートやタイムラインの流れを見ていくなどの取り組みから始められました。

週間ポストモーテムとは関係ありませんが、それ以前は技術トピック座談会というものも存在し、各々が気になっている技術の雑談をするゆるふわな会もあったらしいですがいつのまにか消滅してしまっていました。

社内勉強会あるあるですが、こういった勉強会の継続というのは意外と難しく、2019年からはじまったこの週刊ポストモーテムも、実は「復刻:週刊ポストモーテム」となっていて一度息を潜めそうになってたものを継続できるように改訂していったものになります。

なぜ消滅しそうになったかというと、そんなに頻繁に障害は起きないからです。(発生していても困りますが)

復刻する前のポストモーテムは障害が発生した場合の報告のみを共有していたので、障害がない場合はスキップとなりそれが繰り返されていました。

障害発生時のみ行えばいいのではという意見もあるかも知れませんが、それではその都度スケジュールの調整やメンバーの調整を行わなければならず、開催に伴うコストが増えてしまいます。

また、人によっては障害を起こした人自身が発生原因を語るのは憂鬱になる場合もあり、開催の中でのいくつかの課題が浮き彫りになっていました。

こういった結果「エンジニア全員のサイトに対する興味や学びを上げていく」という本来の目的からずれが生じてしまいました。

SRE本の「ポストモーテム文化の継続」の中での活動例も、今月のポストモーテムと称して、月単位で開催しつつも、過去のポストモーテムなどを振り返り実施しており継続のための取り組みをしっかりと考えているようでした。

復刻:週刊ポストモーテム

前述にもある通りポストモーテムは「組織的な学びのために継続していくもの」であるべきなので、SREチームが主体となりポストモーテム継続のための改定が行われました。

復刻のポイントとして今回は「知見の共有」をメインテーマとして掲げていきました。

そのため復刻したポストモーテムは以下を心がけています。

障害対応した人もしくはそのチームの人が発表

障害を起こした人ではなく、障害を対応した人、もしくはそのチームの人が発表を行います。

障害の原因にフォーカスしてしまうと障害を起こした人が責められる気持ちになってしまうため、 あくまでどうやってリカバリしたのかを重点的に話しています。 (もちろん、原因がわかっているものは原因に触れる分にはOKです。)

障害がなくても開催

障害がない場合でもスキップせずに以下を実施しています。

  • 参加者で監視ダッシュボードを眺める
  • 月一でAWSコストについても確認
  • 時にはポストモーテム以外の共有会も実施

ゆるく開催

  • 祝日はやらない(いちいちずらして調整が面倒)
  • お題がない場合は、事前に話したいことを募集する
  • 資料が揃ってなくてもなんとなく今の状況を話す
  • 参加の強制はしない

など参加しやすい環境づくりも行っています。 また、やることが決まっている場合は当日何をやるかそれとなく共有して興味をひいてもらうように心がけています。

継続して開催していくメリット

もはや名前と内容が違っている時もありますが、本来やりたいこととしては、 「障害からの学びや共有の場を作ることで所属するエンジニア全員のサイトに対する興味や学びを上げていく」 という趣旨のため、名前はこのままで継続していきますが、付加価値をつけたことで様々なメリットが生まれました。

  • みんなの交流の場にもなる
  • 課題を見つけ、なにかをはじめるきっかけになる
  • 他部門の人にクラウドワークスの取り組みを知ってもらえる
  • 監視ツールの使い方や見方をおぼえるきっかけにもなる

みんなの交流の場にもなる

昨今のコロナ渦でリモートワークがデフォルトになってしまったため、オンラインですがみんなで定期的に集まって知見や事象を交流する場が存在するというのは大事なことだと思っています。

課題を見つけ、なにかをはじめるきっかけになる

新たな項目として、監視ダッシュボードを眺めるという回を行った結果、その中で新たな課題や発見が見つかりサイトの改善につながったパターンが何個かありました。

これはエウレカさんで行われているパフォ会にも似たようなものになっており、 こういった定期的なコミュニケーションは頻繁にしたい方です(はな恋風

エウレカさんで行われているパフォ会

他部門の人に知ってもらえる

前まではクラウドワークス(crowdworks.jp)に関わっているエンジニアのみの参加でしたが 今では他の部門(CloudLog)の方なども参加し開催が行われています。

これにより知見の共有を広く周知できるようになりました。

監視ツールの使い方や見方がわかる

これは入社したての方のオンボーディングや、普段見ないような人がツールを見るきっかけにもなります。

  • 監視ツールをどう使うのか
  • 用途毎のダッシュボードやどんな監視項目/アラートが存在するか

など得られる情報はたくさんあります。

今後の課題

また、これからさらに継続・発展していくために、いくつか課題も見えてきました。

ファシリテーションのローテーション

現在SREチームがファシリテーションを行っていますが、できれば参加している他チームも含めたローテーションでファシリテーションを行えるのが理想だと考えています。

他部門の人も発表してもらえるようにする

現在は主にクラウドワークス(crowdworks.jp)のポストモーテムの共有になっていますが、他部門の人が増えてきた場合は他部門のポストモーテムの共有も行っていきたいと考えています。

時間帯が合わない

チームや部門を跨ぐと皆の空いている時間が探しづらくなります。 しっかりと調整を行い全社にこういった取り組みを周知していくのも課題の一つになります。

ファシリテーションスキルをあげる

これは私個人の問題ですが、ファシリテーションスキルが皆無なので、進行の仕方や話し方、取り組みの促進を強化していかないとなと考えています。 ただリモートでのファシリテーションは今でも慣れません。

最後に

ということで今回はクラウドワークスで実施している「週刊ポストモーテム」の取り組みを紹介させていただきました。

クラウドワークスではエンジニアを積極募集しています。 一緒にいろんな知見を共有し、サービスの向上に取り組んでくれるエンジニアの皆様、是非エントリーをお願いします。

www.wantedly.com

www.wantedly.com

© 2016 CrowdWorks, Inc., All rights reserved.