ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

#srefm Production Readiness 会まとめ

はい。こちらのイベントのまとめをしていきます！

t.co

今回はゲストに @koudaiii さんと _a0i さんをお招きして、Application や Infrastructure / Platform の Production Readiness について語りました！

お二人を選んだ理由としては、坂部さんの場合は Production Ready に関するアウトプットがすでにあったということで、すぐに打診しました。aoi さんのほうはサイボウズさんとかどうだろうねということで思いついて声かけました！お二人とも快諾していただき感謝です。

期待とか chaspy の所感とか

hackmd のほうにざーっと書いたやつ。

chaspy の所感

  • Production Readiness Checklist
    • とても良いもので、やってよかった。
    • SRE の負担を最小限にしつつ、Developer も学ぶことが多い様子
    • SRE とサービスチームとの目線の違いをすり合わせないといけない
    • やることが「大変」にならないようにしないといけない
  • Review を SRE がどうやるのか、今後まだまだ洗練させられると思う
    • 実際これまで chaspy メインでみてたので他のメンバーがレビューできる状態かというとそうでもなかったりする
  • 開発者からの Feedback を毎回もらうのが大事
    • 終わってイシュークローズするときにプチ反省会をしてテンプレを更新したりしている。大事
  • Progressive Delivery に適応できるように進化させていく必要があると感じている
    • 今のチェックリストはある一点の時間に、いっきにバーンと公開することを前提としている
    • そのため、試験的に・実験的に・段階的に本番サービスを公開していくような良い取り組みをやったときにいろいろぶつかった
      • Readiness Checklist の項目が終わってないのに出しちゃってアラート飛ぶとか
    • 今後は今の Production Readiness Checklist の項目は残しつつ、プロダクションへのサービスの段階的導入をいくつかモデル化して、それを Design Doc Review 時点で決定し、方向性を合意したのち、Readiness Checklist をいつどこまでどうやって進めていくか、みたいな話をする必要があると考えている

chaspy のこの会への期待

  • Production Ready って何をもって言えるのか、漏れてたりする観点があれば話をする中で見つかるといい
  • 特に一番難しいのはこの Checklist, Template の改善や運用方法。うまくいってる点いってない点あるので共有したい
  • サービス・プラットフォームそれぞれある中で、Production Ready の要素をうまく抽象化できれば便利な気がする

最初の15分ほどもらって、chaspy がやってきた Production Readiness Checklist や Design Doc の内容や運用についてざっと説明しました。

Session1 @koudaiii

事前に素晴らしいアウトプットを用意いただきました。

paper.dropbox.com

Wantedly さんでも導入当初から改善を繰り返しての今で、他のみんなと同様にまだまだ進化の途中ということでした。

驚いたのはこのリストの量ですね。過去のポストモーテムの原因から追記したりしていて、再発防止をしっかりしようとしていることがわかります。

そしてもう1つが、結構ほとんどの項目がやったかやってないかのチェックというよりは、「これは考慮されているか？」という"問い"のチェックリストだということでした。

アプリケーション開発者側では1.5h 想定ですが、インフラチームが見る分量としてはかなり多く、この問診票を持ってヒアリングするのはなかなか大変そうな印象を受けました。アプリケーション開発チームでもこれに自信満々に答えるのはきっと難しいでしょうし、だんだんと洗練されてくるんだろうなあとは思いました。

Session2 aoi さん

事前にいくつか話したいこと、質問したいことを書いてもらったのでそれベースで答えました。

そもそもProduction Readinessをどう始めるのが良いか？

  • chaspyさんのブログを読ませていただいたのですが、あそこに書いてあるよりももう一つ前段階の「はじめかた」を知りたい。
    • SREが必要と思って始めるのだとは思うけれど、そこから開発者の巻き込み方や、チェックリストの制定方法など。

はじめかたのはじめかたですね。

Wantedly の場合だともともと大きなアプリケーションの信頼性が高くないという問題から発信しはじめたということでした。

僕が話したことでいうと、Developer が集まるミーティングで一応広報はしたものの、Readiness Checklist 第1号となるサービス開発チームをつかまえて、これやってみてーといきなりはじめた感じでした。最初は結構つきっきりでやったので、大事なのはこうやって前例を1つ作ること、結構最初はきっちりついて一緒にやること、テンプレートを常に改善し続けること、という当たり前なことをちゃんとやるしかないのかなぁと思っています。

また、今回最初の項目を見直したんですが、めちゃくちゃ薄かったし、全然洗練されてなくて笑いました。以下、公開しますね。

name: Production Readiness Checklist about: Checklist of whether new service works correctly in the production environment.

Production Readiness CheckList for {NEW SERVICE}

Stakeholder

  • [ ] StakeHolder?
    • [ ] Service Owner:
    • [ ] Product Owner:
    • [ ] User:
    • [ ] Reliability: @quipper/sre

System / Architecture

  • [ ] Architecture review with SRE
  • [ ] Create architecture diagram
    • Please include following
      • Traffic pattern: Where does it call from?
      • Dependency
  • [ ] Update <service name>/microservices/service.yaml for dependency
    • [ ] app1
    • [ ] app2

Resources / Load

  • [ ] Access load is predicted: yes / no
    • [ ] comment:
  • [ ] Set Resource(Memory/CPU) limit/request of pods
  • [ ] Set applopriate database connection

Monitoring / Logging

  • [ ] Application: Notify an application error(NewRelic / Sentry?)
    • url:
  • [ ] Synthetic: Notify a synthetics error(Pingdom)
    • url:
  • [ ] Create datadog dashboard
    • url:

Incident / Failure

  • [ ] Circuit breaker is implemented on the caller side: yes / no
  • [ ] Escalation flow
    • flow:

途中でも話しましたが、まぁこんなリストなくてもまずやってるよね、みたいな最小限の項目からはじめて、それをアップデートしていくことが大事なんだとあらためて思いました。1年と少しで70コミットありました。

みんなダッシュボードってどうしてる？乱立しない？

  • 開発者によって何が使いやすいとか、データによってもダッシュボードどれがいいとかあると思うけれど、どうしてます？
  • チェックリストみると統一されているように見えるけれど、他を使いたい・使わざるを得ないみたいなケースはないのか

乱立してるし、秩序もないけど、トラフィックパターンによってインターネットフェイシングかインターナルか、ぐらいは分けられるので、Datadog Dashboard Template を作ってやってもらっています、という回答をしました。

「チェックリストのチェック一個足りないけれどリリースしちゃいたいから後回しにしよう」みたいなケースってないですか？

  • チェックリストが浸透したり、ブラッシュアップされていればそんなことはないと思いますが、最初のうちはそういうことがありそうだなと
  • あとはリリースするサービスの大きさや関わる人数によって変わってきそう

そうならないように、余裕をもってはじめるようにしているし、Readiness 警察を最初の方は結構していた、みたいな話をした気がします。

あとはチェックリスト自体にも問いのものが多いので、「わかっていればいい」「サービスチームがそのリスクを飲めるならいい」みたいな感じで、最終判断はサービスチームに任せる形にしています。

Session3 質問回答

slido によせられた質問に回答していきました！

app.sli.do

リリースしてから長い期間がたったサービスはドキュメントが腐ってしまったり、Production Readinessな状態でなくなることもあると思いますが、再度PRRを実施したりしますか？またそのきっかけはどのようなものですか？

sakabe さんは障害発生時に見直す、ということを言っていたと思います。私はその後見直すことはしませんし、ドキュメントもそのときのスナップショットと割り切っているので、腐ることを許容しています。

Productrion Readiness Checklist はどのように更新、改善されていますか？

Productrion Readiness Checklistの管理はどのようにやってますか？

sakabe さんは google docs, chaspy は GitHub の Issue Template Production に出て行ったあとにフィードバックを開発者からもらう時間を最近はとっています。

非機能要件の整理

今回話している Production Readiness Checklist 自体が非機能要件とか、障害発生時のトリアージができるかどうか、みたいなところにフォーカスしていて、機能要件に関してはサービスチームにお任せしています。

ビジネスサイドとのSLI, SLOの握り方 (どうしてもdevだけで決めて動くことになりがち)

sakabe さんは経営層含めて話して合意したということ。とれるならそのほうが良いですね。 chaspy の場合はあくまで Product Team が自分たちで信頼性をキープするためのツールという位置付け＆ボトムアップではじめたので、プロダクトチームだけで完結しています。Developer と Product Manager と話して決めてもらうようにしています。

Production Readiness Checklistの記載に関して、Yes/Noだと幅が広すぎるため、どの程度達成できているのかぶれる気がしているのですが、その辺り(ぶれる部分)の把握はどのように行っていますか?

これはいずれも"問い"の質問は分かっていれば良い、という感じで、曖昧さを許容している感じだったと思います。

SLIの設計方法やロードテスト時の試験観点、Kubernetesに対する設定項目など専門知識が必要な項目は開発者だけで実施(もしくは実施判断)が難しい気がしますが、どのようなサポートを行っていますか？

Good Question. 結構難しいし、難しいことを強いている自覚はありますが、感謝と尊敬を持っておまかせしています。その代わり密にコミュニケーションをとったり、ギャップが大きそうなことは勉強会をやったり、ドキュメントにちゃんと書く、とかの努力はしています。

プロダクトライフサイクルはどの様な線引きでプロダクトごとにあてはめていますか？

sakabe さん向け、これは線を引くのは難しいよね、って回答だった気がします。

@koudaiiiさんに質問なのですが、これだけのチェックリストを全部に当てていくとインフラ業務のほとんどがこのチェックリストを埋めるので終わったりしませんか？このチェックリストを埋めているのと他の業務の比率はどのくらい取ってますか？

大変なときは大変だよね、楽にしていきたいよね、、、みたいな感じだった気がします。

プレモテームを知らなかったのですが、どんな流れで実施されているのでしょうか？リスク箇所の洗い出しなんかはどの様にやられるのでしょうか？

re:Work が参考になるとのこと。

PRRをスケジュールベースで実施することはありますか？半期/年ごとに１回など。サービス個別に大きな変更はないが、小さい変更が頻繁に行われている場合にはその様な実施方法もありえそう。

現状やってない。やれるならやるのがいいとは思う。が、チェックの自動化とかがもう少しないと厳しい気がする。

リリース前にすべてのチェックが必要でない場合、リリースした後に開発者は自律的に実施していますか？

リスク許容してあとでやりますっていう項目があった場合は、やっていると信じているけど、そこを見届けるまではしてないです。

PoCレベルのサービスに対するProduction Readiness活動は行っていますか? 行っている場合、どのレベルで行っていますか? (他のSLAが決まっているようなStable, GAなサービスと同じレベルですか?)

うちはそれは SLO によって差をつけるとか、Experimental なサービスだからそれをスキップするとちゃんと説明されていれば ok としています。

メルカリさんなんかは松竹梅ランクわけしていて、一時期これを真似しようとしたのですが、うまくワークしませんでした。アーキテクチャが均一じゃないと SLI が同じにならないので難しいと思う。

この Level のやつですね。

Checklistが通らなかった場合、QCDの判断はSRE側でやるのでしょうか？

サービスチーム側で判断してもらう、が回答かな。こちらはあくまで問いとか、やったほうがいいよ、なリストを提供しつつ協力して進めていくというスタンス。

Production Readinessチェックリストを作成するというのは、従来QAが行っていたような受入試験の設計を、SREチームが主導で行うという認識であってますか？

おそらく QA も非機能要件のテストはしていたはずで、その一部を担っていると考えることはできそうです。あってます！

おわりに

個人的にも経験できていろいろ話せるところで、他社の事例を聞けてめちゃくちゃ勉強になりました。特にプラットフォーム側のチェックリストなのかデザインドキュメントなのかについてはまだできてないところで、課題感も一致していることがわかったので、また1年後とかにどうなってる？って話をしたいなーと思いました。

sre.fm 毎月月末にやっていましたが、7月はおやすみです。（飽きたわけではない）

今リクエストもらってるトピックだと

  • CapacityPlanning
  • Monitoring
  • Performance Tuning
  • Kubernetes, Container Orchestration

あたりを事前アンケートでもらいました。

ゲストあってのことなので、僕自身の知識、経験量と、誰を呼べるか、話せるかと、僕自身のモチベーションによってやれたらやれることをやっていきたいと思います。こういうのこのひと呼んでやってよーみたいなのあったら声かけてください！

出演いただいた sakabe さん、aoi さん、ありがとうございました！sakabe さんは昨年の JTF ではじめてお会いして、ずっとファンとして追いかけてるので今回共演できてうれしかったです！終わった後もいろいろな資料、情報共有いただいたので、言語化の力負けないように頑張ります。 aoi さんともなんだかんだイベント共演は初！でできてよかったです。おとうふ君のファンなのでTシャツ間に合ってよかった。プラットフォームの Checklist これからできたら教えてください。これからも情報共有しましょう。あとビール飲みいきましょう。

おしまい！