​​Production Readiness の今
​​
 
Production Ready研修 @ Wantedly - Qiita
この資料は2019年ウォンテッドリーの新人研修資料です。インフラ研修における「Production Ready」の考え方についてまとめたものです。マイクロサービス化が進む中で、個々人またはチームで自信を持ってローンチして、コア・バリュ...
qiita.com
Production Ready研修 @ Wantedly - Qiita • qiita.com
​​
​​この文章は、2019年の新卒研修に書いたものから、さらに改善を進めた今(2020年6月時点)をまとめたもの。
​​
 
sre.fm#2 Production Readiness - HackMD
sre.fm#2 Production Readiness - HackMD •
​​
​​sre.fm で話をする予定です。

​​用語

  • ​​Producttion = 実際にお客様に提供している環境(本番環境)
  • ​​Production / QA / Sandbox = 各アプリケーションが実行されている環境名
  • ​​sidekiq = 非同期処理で実行するジョブ
  • ​​カスケード障害 = 時間の経過とともに連鎖していく障害(SRE本 22章 カスケード障害への対応)
  • ​​RDS = AWS の RDS
  • ​​Elasticache = AWS の Elasticache
​​

​​はじめに

​​成長中のサービスは、さまざまな要因でエンジニアの期待どおりにコードを動かすことが難しい。成長中のサービスの場合、「データ量」・「トラフィック量」の増加、「インフラの増強」、「他マイクロサービスのローンチ」、「スパイク」などによる状況が常に変わり、そのような環境下では、突然あるAPIに繋がらない、DBのタイムアウト、想定外の同時アクセスで過負荷や障害が発生しうるからである。このようなさまざまな要因から書いたコードが常に期待どおりに動くとは限らない。
​​
​​うまくコードを動かす仕組みをインフラチームや運用チームが責任をもつことが多い。インフラチームや運用チームは、「うまくコードを動かす」とはどういう状態を期待しているのかを言語化し、そのために必要なマシンリソースを考え、適切な運用を行う。
​​
  • ​​SREはPRRを通じ、プロダクション環境におけるサービスの信頼性を保証するために自分たちが学んだことや経験を適用しようと努力します。PRRは、SREチームがサービスのプロダクション環境での管理を引き受けるための必要条件と見なされています。
​​
​​Production Readiness Review(PRR) は、「どういったところを考えるべきか」、また「何を守るべきか」を言語化し各自で品質を確認できる状態を作る。リリースエンジニアリング、ローンチコーディネーションチェック、モニタリング、過負荷と障害、キャパシティプランニング、継続的な改善が含まれている。これらのベースとなるドキュメントを見ることで、レビューとレビュアーは品質を確認することができる。
​​
​​Production Readiness ≠ 正しくシステムが動いている
​​どんなに良い設計やきれいなAPIでも価値を出さなければ意味がない。このシステムがなぜ必要なのか？何を提供しているのか？どういった価値を生み出しているのか？これらがわからないものに人的コストや監視コスト、改善コストを掛けるのは難しい。
​​
​​Production Readiness = 継続的に価値が届けられる
​​ユーザーの価値(ビジネスのコア・バリュー体験)が継続的に届けられる状態になっていることを Production Readiness。そのために、モニタリング、アラート、改善サイクル、依存関係の把握、提供する価値そのものの理解といった部分を明確にする。
​​
​​ビジネス・ユーザーの目線から深堀り
  • ​​提供するコア・バリューはなにか?誰に？どのタイミングで？ビジネスのKPIのどこに影響を与える？
  • ​​信頼性を定義し、目標を設定
  • ​​目標を設定したものからどういった指標で見るといいのかを決定
  • ​​その指標に対して、目標に合うように監視やアラートの設定や緊急対応の整備
​​
​​ここまでの流れをインフラチームや各チームで担う SRE や各プロダクトの開発者で価値を理解し、合意をとってシステムの責任と担当範囲を決める。
​​
​​継続的に価値を提供するために
  • ​​何が問題かはわからないが、何かが問題が起きていることを確実に知れる