160724 jtf2016sre

Site Reliability Engineering (SRE)で拡がる運⽤の世界

Googleでの展開から、エンタープライズへの夢は⾒れるか

2016/7/24

http://www.ossl.co.jpTWITTER: http://twitter.com/satoruf

LINKEDIN: http://jp.linkedin.com/in/satorufunai/jaSLIDESHARE: http://www.slideshare.net/sfunai

FACEBOOK: http://www.facebook.com/satoru.funai

OpenProgrammableInfrastructureEnvironment

2016/7/24 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 1

アジェンダ1. SREの定義2. dev-opsとの違い3. エンタープライズとの違い4. 今やるべき事と理由


SREとは

l Site Reliability Engineeringl サイト信頼性⼯学？l 信頼性⼯学とは、システム

の信頼性を分析する⼯学⼿法である。l https://ja.wikipedia.org/wiki/%E4%BF%

A1%E9%A0%BC%E6%80%A7%E5%B7%A5%E5%AD%A6

l しかし、サイト信頼性⼯学という学問はない


SREの求⼈https://www.linkedin.com/jobs/search?keywords=Site%20Reliability%20Engineer&location=united%20states&locationId=&trk=jobs_jserp_search_button_execute&searchOrigin=JSERP



今⽇の元ネタ


こちらも読んでないと、意味わからない


GoogleでのSREの定義l “Fundamentally, it’s what happens when you ask a software engineer to design an

operations function.”l https://landing.google.com/sre/interview/ben-treynor.htmll https://www.usenix.org/conference/srecon14/technical-sessions/presentation/keys-sre

l 「SRE とは、操作機能を作ってくれとソフトウェアエンジニアに頼んだときに起こることだ」l http://googlecloudplatform-japan.blogspot.jp/2016/07/sre-google-mission-

control.html?1468590211542=1&m=1

l Mr. Benjamin Treynor Slossl https://www.linkedin.com/in/benjamin-treynor-sloss-207120l Terse variant: If Google ever stops working, it's my fault.

Verbose variant : I have been responsible for global operations, networking, and production engineering at Google since 2003. As of 2016, I manage a team of approximately 4,000 software, hardware, and network engineers across the globe.Along the way,* I coined the term "Site Reliability Engineering" for my team of (now) x,xxx software engineers engaged in what were traditionally operations functions, and I have watched with some pride as the rest of the SaaS industry has adopted the SRE name, mission, and practices.* I built the networking team, from its initial scope of providing a pair of leased OC48s, to its current size --publicly estimated to be one of the 3 largest networks in the world.* Since 2010 I've also managed datacenter design, construction and operations, and servers. Public estimates are that as of 2014 Google has built between 200MW and 680MW of highly-efficient datacenters worldwide.* Finally, since late 2013 I've been engaged on Google's public cloud product, Google Cloud Platform


Keys to SRE Presentation by Ben Treynor @ SREcon142016/7/24 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 9

SREの範囲

How Google Does Planet-Scale Engineering for Planet-Scale Infra @ GCPNext16


Keys to SRE Presentation by Ben Treynor @ SREcon142016/7/24 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 11

Google SWエンジニア新卒採⽤

必要な条件/経験4 年制⼤学卒または関連職種での実務経験プログラミング能⼒（特に C++ , Java, Python）

望ましい経験/スキル修⼠号または博⼠号を取得していることUnix / Linux または Windows 環境におけるソフトウェア開発や API の経験ネットワークプログラミングやソフトウェアシステムの開発または設計の経験


新卒SWエンジニアが配属される組織l プロダクト＆システムデベロップメント:

l 検索品質を向上させる⾰新的な⽅法の発⾒、コンピューティングプラットフォームやネットワーキング技術の構築、動画のインデックス登録の⾃動化、複雑なオークションシステムの改善・拡⼤など、様々な課題に対してソリューションを開発します。Google のプロダクトの拡⼤と品質向上を実現するためのソフトウェアアプリケーションをリサーチ、企画、開発しながら、⼤量のデータや情報アクセスに関わる問題にチームで取り組むことが求められます。関連する専⾨分野の例として、AJAX および同様の技術を使⽤したユーザーインターフェース開発、セキュリティ、組み込みシステムとモバイルアプリ（Android および iOS）、デベロッパーツール（IDE、⼤規模なビルドシステム、コンパイラ）などが挙げられます。

l エンジニアリングプロダクティビティ: l ソフトウェア設計スキル、分析⼒、プログラミング能⼒を駆使して⾰新的な⾃動テストシステムを構築しま

す。これは、単なるデバッグやテストの実施といった表⾯的な作業のみを指すわけではありません。テストチームは⽇々幅広い課題に取り組みながら、分散コンピューティングインフラストラクチャにおける多様なシナリオに対応するため、インテリジェントシステムの設計と構築を担当します。これまでは存在しなかったものに対する⾃動テストシステムを設計、構築しようとするとき、参照できる教科書はありません。このグループで業務にあたる⼈材として Google が優秀なエンジニアを求めているのはそのためです。

l サイトリライアビリティ: l Google の製品開発プロセス全体に関与し、クラウドベースコンピューティングの最前線で業務にあたりま

す。この精鋭チームの⼀員として、トラフィック異常のコードレベルのトラブルシューティングから最新サービスのメンテナンスまで、またモニタリングやアラートから新しい⾃動化インフラストラクチャの構築まで、Google の運営を維持するあらゆる業務に対応します。このチームのエンジニアは、何千万という数のユーザー規模に⾒合う強靭かつ拡張可能なソフトウェアの作成に情熱を傾けています。⽇々新しく出会う様々な事象に取り組み、ほぼすべてのエンジニアリングチームやオペレーションチームと連携して、すべての⼈がアクセスできるような Google ならではのサービスとアプリケーションを提供します。


GoogleでのSREとはl 全世界に約2,000⼈（SW/NWエンジニア含めて4,000⼈）

l すべての製品／サイトにSREチームがあるわけではない

l 他のチームと共通採⽤、共通⼈材プールl チーム間は対等（Dev. vs Ops.ではない）l チーム間の移動は常に可能l つまり、SREを増員すれば、開発チームはメンバーが減るl Mission Controlプログラム：製品開発に携わるエンジニアに SREの仕事を体験させる 6 か⽉のローテーション

プログラム、実際に受けた⼈間の半分はSREのポジションを選択している

l SREの時間の50%以上は、開発プロジェクトに当てられなければならないl 50%未満になる=運⽤／障害対応時間が50%以上になると、該当製品開発チームに負荷が割り振られるl SREの開発プロジェクトは、⾃動化や監視ツールにとどまらず、サービスレベルの向上に役⽴つもの全て（ロー

ドバランサ、分散合意システム、分散スケジューリング、etc.）l サービス運⽤負荷の５％は製品開発チームが負担する

l 運⽤／障害対応には、チケット処理、障害対応、オンコール（当番）が含まれるl オンコールは、8-12時間交代、時間で25%以下（１週間／⽉）、オンコール中のイベントは２件程度l オンコールは、プライマリーとセカンダリーの⼆⼈体制で、典型的チームは８⼈体制となるl オンコールは、「新⼈の仕事ではない」。オンコールは、トレーニングとチェックリストにパスしないとできな

い。l オンコール中のSREはサービス停⽌を含む、サービスに関する全権を委譲されている。


SRE as a custodian

“SREs are the custodian of production. SREs are the custodian of customer

experience”

「SREとは、サービスとユーザー体験の管理者であり守護者である」

How Google Does Planet-Scale Engineering for Planet-Scale Infra @ GCPNext16


SLAとエラーバジェットl SREチームと製品開発チーム間の契約l エラーバジェット＝100%-SLA(例：99.9%)=0.1%

l エラーバジェット(=SLA)は、製品開発チームが定めるl エラーバジェットを超えた場合は、製品開発チームに対応が割り

振られるl SLAを厳しくすれば、SRE対応可能時間は短くなるl 殆どのSRE対応は、新機能リリース時に発⽣するl つまり、エラーバジェットを使い果たすと、新機能リリースは凍

結せざるをえないl それを避けるためには、リリース前のレビューが重要


リリース前レビューl 必ずPRR：Production Readiness Reviewが、以下の観点でSREと

開発チームで⾏われるl システムアーキテクチャー、他サービスとの依存性l エマージェンシーレスポンスl キャパシティプランニングl 変更管理l 計測：信頼性、応答性、リソース

l PPRの中で、SLA/SLO/SLIを合意し、製品設計に必要なフィードバックを⾏い、トレーニングなどのスケジュールを決定する

l SREの中には、リリース専⾨部隊（LCE: Launch Coordination Engineering）があるl 製品開発チームと協⼒して、関連するチームを横断し⾼品質な製品リリースに

向けてコンサルテーションを⾏うl Google検索から、Andoroidアプリまで全てのGoogle製品に関わる

l もし製品開発チームと合意できなければ、 SREは断れる2016/7/24 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 17

Launch Coordination Checklist例l アーキテクチャー

l アーキテクチャー概要l クライアントからのリクエスト（API）

l マシン／データセンターl 使⽤リソース、帯域幅、データセンターl 冗⻑性、QoSl DNS、ロードバランス

l キャパシティプランニングと性能予測l トラフィック予想l 負荷テスト結果、最⼤応答性能／データセンターl 他サービスへの影響l ストレージ容量予想

l 冗⻑化とフェイルオーバーl サーバー／ラック／クラスター障害発⽣時の挙動l データセンター間NW障害時の挙動l バックエンドサービス障害時の挙動l 障害発⽣時の再起動／回復の⼿順l バックアップ／リストア／DR回復⼿順

l 監視と運⽤l 内部状態の監視と外部からの監視、アラートの設計l 監視システムの監視l ビジネス的に重要なアラートとログの定義l アラートメール攻撃の回避

l セキュリティl スパム対策、脆弱性対策、認証認可設定l リリース前のアクセス制御、ブラックリスト設定

l ⾃動化とマニュアルタスクl 変更管理／プロビジョニング⼿順l リリース⼿順、継続的ビルド／デプロイ⼿順、カナ

リー／ステージドロールアウト⼿順

l スケーリングl スペアリソース、バースト対応、あらーちょl スケーリングのボトルネック、HW/キャッシュ/

データ分割⽅法

l 外部依存性l 依存外部システムのキャパシティl 外部サービス容量超過時のデグレード⽅法


Postmortem Culturel 直訳では検死報告書、障害報告書であるが、内部資料l Blame-freeポリシー：

l ⼈やチームを咎めないl 現象と経過、対応内容と結果を記録し、共有するのが⽬的

l 典型的には下記のような障害発⽣、サービス回復後に作成l ユーザーに影響のあるサービス障害l データ喪失l オンコールエンジニアが対応した障害l 回復に想定以上の時間がかかった場合l 監視に関する障害により、マニュアル作業が発⽣した場合 (オンコールエンジニアにエスカレーションされな

かった)

l 障害発⽣中の対応（chat/mail etc.）はすべて記録されなければならず、Postmortemに反映される

l Postmortemを書くのは、新⼈の仕事ではないl 新⼈教育は、Postmortemを読むことから始まり、Postmortemをベースとしたロールプ

レイトレーニングが実施される

l Postmortem勉強会が常に開催され、優れたPostmortemを書いたエンジニアは、勉強会の講師となり尊敬される


Postmortem例l インシデント#465

l XXシステムPostmortem

l 報告年⽉⽇：

l 著者：

l ステータス：l 完了、アクションアイテム作業中

l 要約：l アクセスピーク時間中に66分間XXシステムサイトサイトダ

ウン

l 影響：l 約１２億ビューの喪失、売上への影響はなし

l 根本原因：l ⾼負荷のためにメモリリークによるリソース不⾜が発⽣し、

ネットワーク負荷が上がった複合障害

l トリガー：l XXモジュールの潜在バグ

l 解決策：l トラフィックをリソースを１０倍に増やしたクラスターにリ

ダイレクトし、負荷を緩和

l 監視結果：l Hhttpp500エラーの多発のため、アラート発報

l アクションアイテム：l 項⽬、タイプ、担当者、チケット番号

l Lessons Learnedl 何がうまくいったかl 監視システムが正常にエラー検出しアラートを発報

l 何がうまくいかなかったかl 初めて経験した複合障害のため、障害原因特定に時間がか

かったl 幸運だった点l バックアップが残っていた

l 経過詳細：l 時間、現象、対応


インシデントレスポンスl ICS: Incident Command Systemがベース

l https://en.wikipedia.org/wiki/Incident_Command_Systeml http://www.bousai.go.jp/kaigirep/kentokai/kentokaigi/04/pdf/shiryo1.pdfl ⽶国で開発された包括的な危機管理体系であり、種類・規模・場所・複雑さ、あらゆる組織に適⽤できる危機管理の考え⽅、

原則を整理したものl 危機管理の標準化（語彙と意味、組織、権限、⼿順など）により、災害対応従事者の協⼒と相互運⽤性を向上させる

l インシデントレスポンスでは、状況に応じて下記の役割を割りあてるl インシデントコマンダー：指揮調整者l オペレーショナルワーク：実際にシステム変更作業を⾏うチーム、他の担当者は操作を許されないl コミュニケーション：記録と関係者への報告l プランニング：オペレーショナルワークをサポートするための各種⼿配、交代要員調整

l コミュニケーションツールl 必ず記録が残るように、メールやIRCなどのチャットツールを使う、Googleではトピックやログを⾃動収集するボットも使⽤l ライブドキュメント：関係者が誰でも読み書きできる掲⽰板、Google Docsなどl 明確な引き継ぎ：誰もがわかるように、内容と業務を明確に引き継ぐ

l インシデントレスポンスのベストプラクティスl 優先順位：⽌⾎、回復、証拠保全l 準備：インシデントレスポンス⼿順の標準化と⽂書化、トレーニングl 信頼：対応チームメンバーへの信頼と委任l 内省：パニックになる前に、⽀援を依頼するl 選択肢の考慮：定期的に選択肢を再検討するl 演習：⾃然に体が動くまで演習を⾏うl 役割交代：すべてのメンバーがすべての役割をこなせるように、都度役割は交代する


⽂書化⼤事l 優秀なエンジニアは、ドキュメント化しなければなら

ないl 知識と技術を暗黙知から、共有し活⽤される知識に変

えるのがドキュメント化l Postmortemだけでなく、チェックリストやマニュアル

など、常にレビュー／アップデートが⾏われるl そのためのミーティングも重視されているl 記録するだけでなく、検索や集計など再利⽤できるこ

とが重要l 勘と度胸の運⽤ではなく、計測とデータによる運⽤




DevOpsとはl 「DevOpsとは開発と運⽤が協⼒し、ビジネスリスク

を軽減する」l http://www.publickey1.jp/blog/11/devops.html

l 初出は、2009年に⾏われた「Velocity 2009」というイベントでFlickrのスタッフが⾏ったプレゼンテーション「10 deploys per day : Dev&Ops cooperation at Flickr」らしい。(https://ja.wikipedia.org/wiki/DevOps)l http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-

ops-cooperation-at-flickr

l この時点では、GoogleはSREを始めて既に６年経過していたが、対外的な積極的発信はしていなかった


「10 deploys per day」から引⽤

DevOpsとは、1. ⾃動化されたインフラ2. 共有バージョン管理3. ワンステップビルドとデプロイ4. 機能フラグによるリリース機能制

限5. DevとOpsの共有メトリクス6. IRCとIMロボット

⽂化1. 尊敬2. 信頼3. 障害への健全な姿勢4. ⼈のせいにしない


SREにあって、DevOpsにないものl ⽂書化l コミュニケーションl レビューl エラーバジェットやPRR、Postmotern、ICSなどの仕

組み


シスアド vs DevOps vs SRE?

l シスアド：何らかの⽬的のためにシステムを設計、構築、正常運転維持、予防保全を⾏う

l DevOps：同上l SRE：同上l 違いは対象とするもの

l シスアド：⼀度構築したら⼤きな変化はないシステムl DevOps：常に迅速な変化が要求されるシステムl SRE：Google




Googleデータセンターl 全世界に１５ヶ所（2016/7現在）l １ヶ所あたり１０万〜４０万台、合計４００万台？以

上のサーバー（推測）


Googleネットワークl グローバルSDN WAN

l 内製HW/SW

l Tb/sのセンター間通信、約900Gb/sのパブリック接続

l 世界第３位のISP


http://postd.cc/how-google-invented-an-amazing-datacenter-network-only-they-could-create/http://www.slideshare.net/oraccha/a-look-inside-googles-data-center-networks

Googleハードウェアl もしかすると世界最⼤のコンピュータメーカー？l OCP（Open Compute Project）にも参加l サーバー、ストレージ、スイッチ、ルーターl 量⼦コンピュータ、TFカスタムチップl 携帯、⾞、メガネ、ロケット？


OCPサーバー

Googleソフトウェアl Linuxベースの独⾃OSl MapReduceをはじめとする独⾃MW、ツールで統⼀さ

れた単⼀環境l Android、Chromel その他Kubernetes、TensorFlowなどOSS


Googleスケールl 2015年度

l 売上⾼$74,541Ml 営業利益$23,425Ml 営業利益率31%l 従業員数約６万⼈l 従業員あたり営業利益$390Kl 全世界84オフィス

l Fortune500の売上⾼94位l IBM 84位、ソフトバンク92位


http://toyokeizai.net/articles/-/64182?page=2

⽇本のエンタープライズ環境l スケール：多くて2,000 - 3,000台のサーバl SW/HW/NW：各ベンダーから調達、異種混在環境l 体制：システム部 -> システム⼦会社 -> Sier -> ２次請

-> 以下⾃粛


結論

我々はGoogleにはなれないしかし、知⾒は活⽤できる




エンタープライズIT

l 広告／ゲーム／Web系とは別世界l 変化しないシステムと変化するシステムの両極分化l 情報システム部⾨無⽤論l 全体的にも、変化速度がゆっくりと増えて⾏くl 古い酒を新しい器に⼊れるような仕事が増えるl 複雑さが増し、従来の運⽤は破綻するl しかし予算は減らされる


バージョン管理

サービスデスク

Open ProgrammableInfrastructure Environment

38

運⽤ポータル

ヒヤリングシート

設定シート

ミドルウェア／アプリ

構成管理

実⾏管理

構築情報

変更依頼

アラート／イベント

API連携

インベントリ／コンフィグ／ステータス

ユーザ

オペレータ

SE

状態監視

vmware

構築/検証

Fabric

物理サーバ

2016/7/24 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved

インベントリ収集

ログ管理

ヒヤリングシート

監視設定Zabbix

構築設定

監視サーバOpenAudIT

GetInfo

インベントリ情報DB

JobScheduler

チケットサーバメール

監視情報

イベント

UI

バージョン管理

GITlab

TeraFormAnsible

ServerSpec

JobMonitoringRedMine

otrs

ZABBIX

Liferay

Packerイメージ作成

ファイルアップロードコンフィグ表⽰（コマンド起動）

ダウンロード

パラメータ作成

GIT連携AWS

VirtualBOXOpenStack

GCPXVMware

OpenPIE2016.04 ヒヤリング

シート

アップロード

xls2json各種設定

パラメータ

CMDBuild

構築cloudconf

コンフィグ作成

Register

Config Deliver

CMDB

Scheduler

Monitoring

OpenPIE概要


ヒヤリングシート例


⾃動化の鍵：ワークフロー制御l ⼈間判断フロー：Enhydra Shark

l 承認、指⽰など各ステークホルダが⼊⼒

l プログラム制御：JobSchedulerl エラー制御、分岐判断のロジックを記述


今やるべき事：経営陣

l 今から５年は、IT技術⼤変⾰期l 今までの技術停滞期に合わせた体制では、

破綻するl 変⾰期に合わせた⼈員配分と組織編成を

再考するべき


今やるべき事：管理職

もっと勉強しろマスコミやベンダー情報は１０年遅れている


今やるべき事：現場l 転職活動l 開発部⾨も運⽤部⾨も

l Excel/Word/Powerpointの⼿順書はコード化l コード化すれば、ドキュメントを⽣成する⽅法はあるl コーディング／レビュー／テストを、運⽤と開発で

共通化標準化l 計測し、記録し、⽂書化し、共有知化する仕組みを作るl 記録するだけでなく、検索や集計など再利⽤できることが重要

l 勘と度胸の運⽤ではなく、計測とデータによる運⽤2016/7/24 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 44

最後に

企業⽂化は⾃然に醸成されるものではなく、設計／構築／維持管理が必要な繊細なシステム


参考資料l Site Reliability Engineering - How Google Runs Production Systems

l https://www.amazon.co.jp/Site-Reliability-Engineering-Production-Systems/dp/149192912X

l クラウドを⽀える技術 ―データセンターサイズのマシン設計法⼊⾨l https://www.amazon.co.jp/%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%

8A%80%E8%A1%93-%E2%80%95%E3%83%87%E3%83%BC%E3%82%BF%E3%82%BB%E3%83%B3%E3%82%BF%E3%83%BC%E3%82%B5%E3%82%A4%E3%82%BA%E3%81%AE%E3%83%9E%E3%82%B7%E3%83%B3%E8%A8%AD%E8%A8%88%E6%B3%95%E5%85%A5%E9%96%80-WEB-PRESS-plus/dp/4774167304/ref=sr_1_sc_2?ie=UTF8&qid=1468737268&sr=8-2-spell&keywords=datacenter+as+acomputer

l What is ‘Site Reliability Engineering’?l https://landing.google.com/sre/interview/ben-treynor.html

l Keys to SRE Presentation by Ben Treynor @ SREcon14l https://www.usenix.org/conference/srecon14/technical-sessions/presentation/keys-sre

l How Google Does Planet-Scale Engineering for Planet-Scale Infra @ GCPNext16l https://youtu.be/H4vMcD7zKM0

l Love DevOps? Wait 'till you meet SREl https://www.atlassian.com/it-service/site-reliability-engineering-sre

l Hiring Site Reliability Engineersl https://www.usenix.org/system/files/login/articles/login_june_07_jones.pdf

l The Systems Engineering Side of SiteReliability Engineeringl https://www.usenix.org/system/files/login/articles/login_june_08_hixson.pdf

l Weathering the Unexpectedl http://delivery.acm.org/10.1145/2380000/2371516/p30-krishnan.pdf

l Borg, Omega, and Kubernetesl http://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/44843.pdf


Technology

160724 jtf2016sre