DevOpsなマインドセットと組織文化の醸成を促すためにSREプラクティスを活用してやっている事

shodai

はじめに

とある常駐先で7月からの半年間の中でプロダクトチームのテックリードとして「組織としてのDevOps力」を向上させるために「DevOpsなマインドセットと組織文化の醸成を促すためにSREプラクティスを活用してやっている事」について考えて考えていた事とやった事を書きます。

DevOpsと組織文化

まずDevOpsという言葉についてですが、wikipediaから引用してしまいます。

DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす

引用: https://ja.wikipedia.org/wiki/DevOps

これに対し、DevOpsという概念を実現させるために必要なものが、

1. IaCやCI/CDなどテクニカルツール
2. SREプラクティスやマインドセットあるいは組織文化

と解釈しています。

前者のテクニカル面でのアプローチやツールを活用する知見も必須ですが、この記事では後者のマインドセットあるいは組織文化をどう醸成しているかを書いてきます。

組織文化とマインドセット

組織文化として根付くためには組織全体で長い時間をかけて以下の様なものを丁寧に醸成していると考えています。

1. 価値観の共有
2. 共通の目的意識
3. 暗黙的な意思決定や行動ルール

価値観を共有し、共通の目的意識を持つことで、暗黙的な意思決定や行動を起こせる状態が、文化として根付いている状態だと考えています。

そのために自分は組織に対し知見共有や場を作ったときっかけを作る事で、促進を促す必要があると考えていて、そのためにSREプラクティスを活用し、以下の取り組みを行いました。

1. 共通の目的を明示するSLO/SLI定義。
2. 目的と現状の再確認のを行うPWG(PerformanceWorkingGroup)。
3. 組織としての継続的な学習と原因を深く理解するためのポストモーテム。

このあとはそれぞれを詳しく書いていきます。

SLO/SLI定義

共通の目的を明示するSLO/SLI定義を行いました。継続的な改善を行うために必須な定量化ですが、文化や組織に与える影響としては、数字として表現する事で、状況を把握しやすく暗黙的な意思決定や行動ルールを促すと考えています。

SLO/SLIはチーム全体で運用する事に意味があるので、チームの中で一定の知見共有や理解が進むまで、SLOとはどういうものか？SLIにはどんな例があるか？どう運用されるのか？など時間をかけて丁寧に共有していきました。

SLO/SLIの理解がチームに程度浸透してきたタイミングで、具体的に「自分たちのサービスの中でユーザーにとってのペイン、ゲインに大きく関わる指標は何か」を検討しました。

自分一人で考えてアウトプットを出しても浸透はせずチームのものにならないと考え、Pdmとサービスの特性や価値とそれを表現できるSLIの大枠を作り、それを元にチーム全体でディスカッションをしていきました。
合わせて組織横断のSREチームのエンジニアとも相談や認識合わせを行いSLO/SLIを練り込んでいきました。

また、SLOが鮮明に定義できたタイミングでグラフでの可視化を行いました。AWSメトリクスから算出するSLOにはDataDogを、ログから算出するSLOにはRedashを使いました。
継続的に調整していく事や、チームで運用する為に、グラフ化自体の作業もチームメンバーと協力して作成しました。

PWG(PaformanceWorkingGroup)

目的と現状の再確認を行うPWG(PerformanceWorkingGroup)です。

元々は、実際に運用していく中で毎月1回チーム全体でSLO/SLIを確認しようとしていたところPWGというワークショップを教えて頂きました。

定期的にPWG（Performance Working Group）と呼ばれる会を開き、開発チームのエンジニアとインフラ担当が最近のパフォーマンス状況やサーバ構成の変更を共有します。

引用: https://mackerel.io/ja/blog/entry/advent-calendar2015/day19

PWG自体の情報が少なくワークショップ自体も育てていくつもりですが、「SRE業務をプロダクトチームとSREチームと共有する」という観点から、現状は以下の観点でSREチーム、プロダクトチームで情報共有やブラッシュアップを行っています。

・直近1ヵ月上がったアラートとその対応
・インフラ構成の変更
・今後1ヶ月で予定されているパフォーマンス変化に寄与しそうなイベント
・SLI/SLO低下の要因確認と見直し

また、SREチーム以外の他チームのメンバーをゲストとして参加して頂き、新しい観点でのアドバイスをいただいています。これは、今後、他チームへの横展開を行い、エンジニア組織全体のSREスキル向上や文化醸成への布石にしたいという考えがあります。

情報共有や観察し気づいた傾向の共有、リマインドから始めて、課題感を共有する事でそれに対する組織の自発的な改善アクションを促し暗黙的な意思決定や行動ルールを醸成していく場にしたいと考えています。

ポストモーテム

組織としての継続的な学習と原因を深く理解するためのポストモーテムです。ポストモーテムについての説明は以下の記事が分かりやすいと思います。

ポストモーテム（Postmortem）とは想定外のインシデントが発生した後に書かれる内部向けの報告書である。

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

DevOpsにおいて、想定外のインシデント(システム障害)は避けられないのですが、それに対する価値観の共有はしておく必要があると考えています。

具体的には、「インシデントは絶対的にダメなものだから、原因を特定し再発防止を徹底するためのポストモーテム」の様な価値観、ムードだとネガティブで萎縮され、開発体験の悪い組織文化になってしまうと考えています。
そうではなくて、「インシデント発生は避けられないもの。その上で発生したインシデントに対し深く理解し学んだ事を共有し、改善するためのポストモーテム」という価値観、ムードを共有する事が必要だと考えています。

品質の向上や、SLO/SLIへの貢献などのインシデント管理としての恩恵とは別に、組織への影響としては、PWGと重なりる部分も多く、ポストモーテムを通し、インシデントの原因を深く理解した上で共通の認識を持つ事で、それに対する組織の自発的な、予防、改善アクションを促し暗黙的な意思決定や行動ルールを醸成していく場にしたいと考えています。

終わりに

以上が一部ですが、DevOpsなマインドセットと組織文化の醸成のためにSREプラクティスを活用し取り組んでいる内容でした。
いずれの内容も自分一人でできる事はなく、組織全体で向き合っているからこそワークしているものだと日々感じています。これらの活動を組織全体で始めて改善していく中で自然と組織文化が醸成されていくものだと考えています。