プロダクション運用に必要な項目の定義とドキュメント化の実践

この記事は「Eureka Advent Calendar 2021」4日目の記事です。

こんにちは、SREチームのエンジニアの@marnie0301 です。
2021年もあっというまにすぎてしまいましたね。
季節も冬になり、猫が自然と添い寝してくれる季節になりました。

幸せですね。我が家の猫は四角になりつつあります。

このまま猫の話を続けたいところではありますが、
今回は、チームでプロダクション運用に必要な項目を定義して
ドキュメント化している話について紹介していけたらと思います。

直面していた課題感

私の所属するSREチームは、2021年12月現在はプロダクションで利用するシステム群を4名で構築・運用しています。

横断的に各プロダクト、マイクロサービス、プロジェクト、ロールから依頼を受け取り、の面倒を見るチームである為、
ある程度のレベルまではどのシステムついても各種業務を各人で持ち回れる程度の柔軟性とセキュリティ・プライバシー、データ周りのような長期での取り組みが必要な案件には専属で人をアサインするという
二つの特性を持ったプロジェクトをバランス良く遂行していく必要がありました。

その結果、チームでは以下のような課題感がありました。

• セキュリティやプライバシーのような要件にある程度、長期で全社としてプロジェクトが組まれている複雑性があるものについては、メインで見ている人とそうでない人で認識に大分差が生まれている。
• システムによって必要な改善の度合いや構成がまちまちであり、各システムがどのような状態かを把握しづらい。
• 情報がwikiの各種プロジェクトページに散らばっており、検索で見つけるのが大変＋どれが最新かわからない。
• SQS+Lambdaのようなイベント駆動型の処理系統を内包しているものもあり、IaCだけでは全体感を把握できない。
• ドキュメントの記述方法もまちまちで必要な項目が足りていなかったりする。書くべき情報が定まってないので書きづらい。

総じて、プロダクション運用において必要な対応項目が網羅的に確認できる状態になく、要件によって、担当も入れ替わり立ち替わるので、
一つのシステムにおいて必要な情報が各人・各プロジェクトページに分散しており、常に認知負荷とコミュニケーションコストが高い状態でした。

目指すべき状態を考えてみる

現状直面している課題ベースだけで考えると各システムに対して、各人に散っているナレッジをより詳細に記載しましょう！で終わりかもしれません。
一方で、エウレカのSREチームが掲げているミッションの一つに以下のようなものがあります。

エウレカのSREチームはサービスやビジネスの成長を阻害しない（むしろ加速させる）チームである。

これはビジネスのスケールを支える為に開発組織自体がビジネスの拡大に追随してスケーラブルである状態を作れるようにリードしていこうという意味を持っています。

今後のビジネス規模の拡大やサービスの数カ国同時展開など、ビジネス拡大の速度がより加速した際に、数名の限られたメンバーだけがこの関心ごとを維持してSREだけが把握している状態は果たしてスケーラブルでしょうか？おそらくは私たちがボトルネックになる未来が待っていると思います。（つらい）

導かれた結論

結論として私たちは、チームで以下の役割を担うドキュメントの作成と維持を標準化していく事としました。

• 担当が入れ替わってもスィッチングコストや認知負荷を緩和する重要な項目が常にメンテナンスされているサマリとしての役割
• 今後、SREの人員入れ替えや追加が起きた際だけでなく、開発者自身が業務範囲を拡大する際に必要な考慮事項に気づけるガイドラインとしての役割

具体的に必要な項目を定義する

作るべきものの目的が定まったので、次は具体的に私たち(開発者)がプロダクション運用に求める事、維持していきたい事を分解し、項目化していきます。

• アーキテクチャー図

全体を俯瞰して認識できるように構成されている方が認知負荷は低いので、必ず作成しています。
昨今のイベント駆動型のアーキテクチャや、データの流れなどについては、コードだけでその全体像を追うのは非常に難しいので、ある程度可視化したい意図もあります。

• 対障害性・信頼性

可用性を維持できる必要な冗長構成がとられているか？単一の障害点を持っているのか？外部に依存しているのか？等について考慮する項目です。

• スケーラビリティとボトルネック

リクエスト・利用者の増加などに対してスケールアウト可能な構成がとられているか、や何を元にスケールしているか、どんなボトルネックを抱えているか？コストはどのように拡大していくのか？などについて考慮する項目です。概ねのマネージドサービスはスケーラビリティを考慮する必要がないと思われがちですが、細かく確認すると様々な制約について知っておく必要があります。(例えばlambdaなら、同時実行数制約など）

• システムダウン時に起き得る影響の記載/ポストモーテムへのリンク

予想できるシステムダウン時に起きるビジネス的な損害や、必要な連絡先を記載します。これはインシデント発生時に必要な情報共有や各処理(広告出稿を止める、ユーザーへの告知をする等)を行う為に必要な項目です。

• セキュリティ

外部公開の有無や、認証/認可やネットワークがどのようなACLを持つべきか？ PCI-DSSなどに準拠する必要があるのか？などを記載しています。

ドキュメントだけではなくBridgeCrewやsynkのようなサービスも併用して、必要な検査と対応状況が把握できる状態を作っています。

セキュリティ１項目だけでかなり大きな話になるので、ここまでは詳細は割愛します(sorry)

• プライバシーデータの有無と必要な処置について

エウレカの所有するシステでは、データの分類によって必要な暗号化やルールの適用が全社で定められています。定められた管理基準を満たしているか？を記載しています。

• Delivery

デプロイ方法、切り戻し手順・切り戻しに必要な時間などについて記載する項目です。

• SLO/SLI

システムが正常であり、ユーザーに安定して価値を提供している、と判断するために測定するべき品質（操作）はなにか？を記載します。SLOとSLIは、監視するべき最上位の項目でもあるべきなので、とても重要な項目です。

• 監視/モニタリング

SLO/SLIで定めた項目についアラートが貼られているかや、Datadogのダッシュボードで必要な情報が作成されているか？

• logging

アプリケーションログ、アクセスログなどのトラブルシューティングやあらーとのソースとなるログがどこに保存されていて、どのように担保されているか？

などなど。ドキュメントではなく、横断的に用意できるに越したことはない項目も今時点ではありますが、それらは今後別の手段で自動で提供できるないかを検討しています。

実際に運用してみて

できあがったドキュメントの項目はテンプレート化されているので、単純な情報の集合ではなく、私たちがプロダクション運用する上でシステムに必要な関心ごとのガイドラインを表現する事ができました。

現時点で、このドキュメントはプロジェクトの終了に伴って人員をスイッチングをする際のコミュニケーションコストや、認知負荷を和らげるだけでなく、各自の進行しているプロジェクトの終了時にチームメンバーでレビューして、各人の理解を深める事や不足している事はないかなどを話し合う土台として、価値を提供してくれています。

ドキュメントは陳腐化するから作っても無駄なのか？

ドキュメントは陳腐化しやすいという問題点を内包しています。(他人事のように言っていますが、私自身、腐らせたことが何度かあります。)

確かに、ビジネスに素早く対応するという現在のシステム開発において、リリースは毎日（多ければ日に5~10回)であり、その変更に詳細に
追随し続けることは容易ではありません。

ただ、今回、私たちが運用したいドキュメントは全てのリリースの修正を反映しなければならないレベルの粒度ではなく、ポリシーや重要な情報のみを抜き出したサマリーです。必要な変更頻度は、日々のプログラミングの適用に比べれば、そこまでのものではありません。

2021年現在、私たち、SREチームは上述したドキュメントを維持し続けるコストが現実的に支払い可能である事とコスト以上のメリットをもたらすだろうという事について合意し、チームの各自が遂行するプロジェクトの最終受け入れ条件に定める事で運用しています :)

チーム外への拡散と最適化

現時点では、上記のドキュメントはSREチームでのみ運用されていますが、チームで運用を一定期間続けて、使い方や過不足について再評価と修正を行なっていき、今後は先に述べたような、開発組織で共通で使えるガイドとして、使用していく事を考えています。

結び

今回はエウレカのSREチームが実践した取り組みの一つを紹介させていただきました。似たような課題感や目標観がある場合は、ぜひ議論の肴にしていただけたら。それでは皆様、良いお年を！