Successfully reported this slideshow.
Your SlideShare is downloading. ×

SRE_WORKBOOK_CH3_THD

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ch3.20180903
ホームデポについて
北⽶2,200リアル店舗と店頭商品35.000個
400,000の従業員
オンライン店舗の商品1,500,000件
オンライン訪問数2,000,000,000件/年
商取引1,500,000,000...
SLOという共通の⽂化を構築することで、上記のような分断を解消を⽬指すためには、
⼈材、プロセス、テクノロジーに影響するような包括的な戦略が必要で
4つのエリアにまたがっていた
共通の⺟国語
THDの⽂脈に即したSLOの定義
⼀貫性のある⽅法で...
た
平均よりもパーセンタイルで測定することとした
エラー
HTTPステータス4xx/5xx両⽅を追跡するが、
5xxのみをSLOとした。
Ticket
SLOとは⼀緒に、(不具合)チケットも追跡することとした
(不具合)チケットはソフトウェアの...
Advertisement

Check these out next

1 of 7 Ad
Advertisement

More Related Content

Recently uploaded (20)

Advertisement

SRE_WORKBOOK_CH3_THD

  1. 1. Ch3.20180903 ホームデポについて 北⽶2,200リアル店舗と店頭商品35.000個 400,000の従業員 オンライン店舗の商品1,500,000件 オンライン訪問数2,000,000,000件/年 商取引1,500,000,000件/年 (マイクロサービス化された)各サービスは以下の質問に回答できるか? ⾃分達のサービスの信頼性はどのくらいか? 99.9%? 99.95%? 99.99% もしくはそれ以上? 計画停⽌はあるか? レイテンシの上限値はどの程度か? (送信しようとする)リクエストを処理できるか? 過負荷をどのように処理するのか? 経年劣化せずにSLOを達成できているか? (回答できるのであれば)サービス間の依存関係も明確になっているし、 (サービスの所有する)各チーム間でのコミュニケーションもより潤滑にあり、 信頼関係も説明責任もより強化されるはず SLOを採択するまではDevsとOps間で以下のような(情報の)分断があった モニタリングツールとダッシュボードは豊富にあったが、 ぞれぞれ散在し、データの時間遷移をトラックすることはしていなかった サービスの障害点をピンポイントで特定することはできず、 (しばしば)エンドユーザーと同じ視点から始めて、 バックエンドへと調査を進め、多くの時間を浪費していた。 1チームが計画停⽌を⾏う場合、(それに依存する)他チームが驚くような状態 SLA99.95%のサービスを構築する場合でも、 ⾃分達が依存するサービスがSLA99.99%以上を保証しているかを把握していなかっ た ホームデポ(THD)でのSLO事例 SLO⽂化に⾄るまでの道のり(The SLO Culture Project)
  2. 2. SLOという共通の⽂化を構築することで、上記のような分断を解消を⽬指すためには、 ⼈材、プロセス、テクノロジーに影響するような包括的な戦略が必要で 4つのエリアにまたがっていた 共通の⺟国語 THDの⽂脈に即したSLOの定義 ⼀貫性のある⽅法で計測⽅法の定義 伝道(会社全体に⽤語を伝える) なぜSLOが⼤切かを説く研修資料、社内⾏脚(巡業)、社内ブログ、宣伝素材の準 備 SLQ実現のアーリーアダプターを⼿配し、その価値を横展開する キャッチーな略語(VALET)を作り、SLO⽂化の浸透を加速 研修プログラム(FiRE)の準備 ⾃動化(されていること) SLOを採⽤するさいの、摩擦を軽減するために、 サービスレベルを表す指標(SLIs)が⾃動で収集されるような仕組みが必要 インセンティブ(報酬) DevsリーダーがSLOを設け、測定するための年間⽬標を準備する チケット(サポート部⾨の起票) アプリケーションの信頼性をはかる唯⼀の指標 APIの可⽤性とレイテンシ インフラ(リソース)の利⽤率 トラフィック量 リソース計画の⽂化が無かったため、開発と運⽤チームとの間で サービスが処理できるトラフィック量がどのくらいかを議論する必要があった トラフィックそのものはサービスへのリクエストと定義するのは容易だったが、 平均リクエスト数/秒、ピークリクエスト数/秒、⼀定期間のリクエスト総数のど れを 追跡するかを決める必要があった どの指標も追跡し、各サービス毎に適切な指標を選択できるようにした。 (そもそも)外的要因の⼤きいリクエスト総数をSLOに含めるべきか議論したが、 ⼩売業は、ピーク時にあわせてサービス規模を決定することは必要なので、 (予想される)ピークに対するリソースに関するSLOを採⽤した レイテンシ サービス毎にレイテンシに関するSLOを⽤意し、測定する箇所を決定した ネットワーク、キャッシュ、プロキシといったマイクロサービス外の要因で 発⽣する事象を検知できるホワイトボックスで監視(分析)できることを条件とし 最初に採択されたSLO
  3. 3. た 平均よりもパーセンタイルで測定することとした エラー HTTPステータス4xx/5xx両⽅を追跡するが、 5xxのみをSLOとした。 Ticket SLOとは⼀緒に、(不具合)チケットも追跡することとした (不具合)チケットはソフトウェアの操作性レベルを⽰唆するもの VALET SLOの頭⽂字を並べて新しい標語(VALET)とした Volume(traffic) :どのくらいのトラフィックを処理できるか Availability :サービスは稼働しているか Latency :サービスは素早く応答しているか Errors :サービスはエラーを返すか Tickets :サービスは操作上、⼈の介⼊を必要とするか   訳注   VALET=(貴人の)付き人 SLOを社内全体に伝えていく必要があった SLOがなぜ重要なのか SLOが「⾃由と責任」⽂化をどう⽀えるのか 何が計測されるべきか (計測)結果をどう扱うか 開発者が(今後は)opsにも責任をもつことになったが、 そもそもSLA/SLOの概念に不慣れ なため、教育が必要だった。 経営幹部のバックアップも必要だったし、 開発者⼀⼈⼀⼈に、従来の⼿動のメトリック 追跡から VALETのフレームワークに移管することを説いて回った。 逆に、SLOのレポー トを定期的に経営幹部に提出することも⾏った。 伝道するにあたって以下のような⽅法も利⽤した 社内ブログでVALETや信頼性、外部リンクなどを準備 GoogleのSREを招いてのTeckTalks(勉強会)を実施 (後にFiRE Academyにつながる)ワークショップを開催 SLOの伝道
  4. 4. 社販で(ノートPCに貼る)シールとかTシャツとかを準備 VALET(という⽤語)は社内に広まり、 SLOはビジネスの年間指標にも⽤いられるようになった。 50を超えるサービスの開 発チームの週次の分析にも利⽤されている。 結果的に、データの⾃動収集の必要性が⾼まっていった。 SLO⽂化の浸透を⾜がかりに、データ収集の⾃動化が、SLOの採⽤を加速させたていった TPSレポート(Transactions per second) GCP上で動いているサービスがVALETのデータ分 析を取得する仕組を⽤意 TPSレポート⾃体はBigQueryで実装されていて、 時間単位のVALETデータに変換され、 誰でもQueryを書くことが出来る 最新情報、前週⽐、SLOの未達といったビジネス上のレポートが chatbotで⾃動で送られ るような実装となっている VALETサービスはトレンディングツールとして、 ⽇次、週次、⽉次といった粒度でSLO を追跡することができる エラーバジェット管理のためにも利⽤できるが、 監視システムとは連動していない GCP上で動いていないサービスに対してもAPIを提供し、 TPSレポートを通さずに VALETサービスにデータを投⼊できる VALETのデータ収集を⾃動化 TPS Reports VALET service
  5. 5. SLOの⽂化がいったんうまく回り出すと、新しいSLOの普及も加速されます。 VALET ダッシュボード ※省略 SLOの普及
  6. 6. 初年度には50のサービスが対象だったのが、 毎⽉50のサービスがVALETに登録され、その数は800を超えている Volume:処理されたレコード量 Availability:どの位のジョブが⼀定時間内に処理されたか Latency:ジョブの実⾏に要した時間 Errors:処理に失敗したレコード Tickets:オペレータが⼿動でデータを直し、再実⾏した回数 破壊的なテストをステージング環境で実施し、VALETデータを記録。 VALETデータから サービスへの影響(願わくば影響がないこと)を確認する      訳注      https://www.infoq.com/jp/news/2015/10/netflix-chaos-engineering Googleのようなエラーバジェット⽂化の採⽤ SLOが不達成の場合、新機能のリリー スを停⽌する 現在はサービス全体でSLOを計測しているが、 end-point毎にデータ取得している SLOはWebのエンドユーザーごとの待ち時間、 レンダリング開始からレンダリング 完了までの時間をも計測したい サーバーが、ゾーンが、リージョンが切り替わるまでといった デリバリの時間も VALETの対象としたい サービスの依存関係と、VALETが採⽤されていないサービスを 視覚的に表⽰するこ とも⾏いたい SLOはプロダクトマネージャーと呼ばれるような、ビジネス責任者によって策定され るべきだが、技術者ではない責任者にはSLOはあまり直感的ではないので、 99.5%: 店舗関係者が利⽤していないアプリケーション 99.9%: THDの販売に関わらないシステムの⼤半 新規サービスのMVP(Mimnimum Viable Product)  訳注  https://growthhackjournal.com/mvp/ 99.95%: 販売システムもしくはそれをサポートするシステム VALETをバッチに適⽤する VALETをテスト(製品評価)に利⽤する 将来に向けて
  7. 7. 99.99%: インフラサービス といった、メトリクスとビジネスを結びつけて共有することで、 ⼤企業で⾒られる期待 値のギャップを回避することができる 伝統的な⼤企業にあってはSLO採⽤は難しく感じるかもしれないが、 THDもまた伝統的 な企業で有り、 すべてを⼀度に始める必要はないですし、1つ1つ進めている⼀⽅で、 伝道を進める戦略 とインセンティブの策定が迅速な変⾰を可能にした。 (⼀年以内に800ものサービスが SLOを採⽤した) SLOとエラーバジェットの概念は強⼒で、様々な問題に適⽤できる。 SLOは進⾏形のプロセスであり、⼀度きりの変更ではすまないものである。 Evernote/THDとも、Google(サービス)を利⽤しているが、Google固有のものではない。 企業毎に独⾃の環境にSLOを導⼊することができる サマリ 第三章のまとめ

×