site reliability engineering (sre)を可能にするopenpieのご紹介

Site Reliability Engineering (SRE)を可能にするOpenPIEのご紹介

2016/9/12

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

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

Enabling SRE

2016/9/12 OSS運⽤管理勉強会主催セミナークラウド時代のIT運⽤管理〜OSSツールは商⽤ツールに追いついたか？〜

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


今⽇の元ネタ


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


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


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/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 11

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 2015年度実績

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

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

l 全世界に１５ヶ所（2016/7現在）のDC

l １ヶ所あたり１０万〜４０万台、合計４００万台？以上のサーバー（推測）

l 内製HW/SW

l グローバルSDN WAN

2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 23http://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 しかし予算は減らされる


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

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

共通化標準化l 計測し、記録し、⽂書化し、共有知化する仕組

みを作るl 記録するだけでなく、検索や集計など再利⽤できることが重要

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


SREを実現する

l OpenPIEの⽬的は運⽤⾃動化そのものではなく、すべてのオペレーション、機器情報や障害対応を記録し、情報共有・分析によるSRE (Site Reliability Engineering)を可能にすることです。

SREを実現する

l 運⽤ポータル：l Liferayポートレットにより必要な情報が⼀覧でき、表⽰情報はユーザー⾃⾝でカスタ

マイズ可能です

l プロビジョニング：l Excelで作成した設定シートをアップロードするだけで、⾃動的にサーバーを作成し

アプリケーションをインストール・設定します

l インベントリ収集／構成管理：l 管理対象機器から、構成情報を⾃動収集します

l システム監視：l プロビジョニングされたシステムを、⾃動的に監視開始します

l アラート⾃動対応：l システム監視が発報したアラートから⾃動的にチケットを作成し、予め登録した⼿順

に従い対象システムにログイン・ログ収集・プロセス再起動などを実⾏します。

運⽤管理⾃動化製品例運用ポータル

ジョブモニタリソースモニタチケットモニタカレンダ

イベントモニタ

ニュース

監視／アラート

サービスデスク／構成管理／変更管理

チケット作成障害通知

プロジェクト管理作業依頼

ソースコード管理

コード作成／修正

デプロイツール

ジョブ管理

クラウドAPI

テストデバッグリリース

クラウド

プロバイダ

リソース結果登録

オーケストレーションレイヤ

イメージ置場

レポジトリ

CMDB

メール


ネットワーク管理

アプリケーションフレームワーク

監視

資源管理（クラウド／VM／実機／ストレー

ジ）

OSインストール初期設定／構成管理

アプリケーション構成

コマンド⾃動実⾏

openQRMCMDBuild

KubernetesGlusterFS

CephXtreemFS

PuppetAnsible

Nag

ios

Zabb

ix

Fabric

運⽤管理⾃動化OSSツール

JobScheduler

Open ContrailEtc.

ジョブ管理


サー

ビス

デス

ク／

⼯程

管理

／リ

ポジ

トリ

Redm

ine

Git

/svn

OTR

S

Open Programmable InfrastructureEnvironment

バージョン管理

サービスデスク

運⽤ポータル設定シート

アップロード

ミドルウェア／アプリ

構成管理

実⾏管理

システム監視

vmware

プロビジョニング

物理サーバ

インベントリ収集

パラメータ作成

Apply/Destroy

コマンド実⾏

チケット⽣成

監視設定

ツールの選択l エコシステム

l 情報量l コミュニティl 商⽤サポート

l ⽇本語サポートl 国際化(i18n)対応l ドキュメント

l APIl 外部API(SOAP/Rest)l 内部API(Java/Java Script/Python/Ruby/Perl/Php etc.)


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

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

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


ジョブ管理：JobSchedulerの特⻑l オープンソース（GNU Public License V.2）

l Linux/Windows版は、全ての機能が無料で使⽤可能。l サポートライセンスを購⼊すれば、HP-UX/Solaris/AIX版の利⽤に加えて、障害対応、

バグフィックス／ワークアラウンドの提供、新機能の早期提供、チケットシステム(OTRS)、JIRAの利⽤が提供される。

l プログラマブルl ジョブの中で、Java, Perl, JavaScript, VBScript, Powershell, javax.scriptの内部APIを

使ったロジックを記述可能l 外部API（XML形式）によりRESTまたはコマンドラインからジョブの実⾏制御、実⾏

状況の取得が可能

l エンタープライズ・グレードl ファイル転送やログローテンション等豊富なテンプレート機能l リモートジョブ実⾏、冗⻑化機能、ロードバランス、外部認証等、エンタープライズ

向け⼤規模システム対応l JasperReport（ジョブ実⾏レポート）やZabbix/Nagios（ジョブ実⾏監視）との連携機

能l MySQLの他、PostgreSQL, Oracle, DB2, MS SQL Server, Firebirdに対応

l 豊富な導⼊実績2016/9/12 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 36

JobScheduler V.1.11ジョブフロー画⾯

CMDBuild構成管理システムl 2005年プロジェクト開始l 伊Tecnoteca 社が開発、AGPLライセンスl http://www.cmdbuild.org/


CMDB


ワークフロー

文書管理

地理情報

レポーティング

APIJSON/SOAP

APACHETOMCAT

アセット

コンピュータライセンス

サーバデスクトップ

ユーザサプライヤ

ドキュメント

場所

保守契約

監視システム

ポータル

ワークフロー機能


l Together Workflow Editorで作成したワークフローを、インポートhttp://www.together.at/prod/workflow/twe

Redmine'>)Cmdbuild)

)

)

or

Redmine

Redmine

XRFC

X X X

)

)X

Redmine) ))

X

X

XRFC01 RFC02

RFC03

RFC04 RFC05

RFC00

RFC06

RFC07

RFC08

RFC09 RFC10

RFC11

RFC12

RFC13

RFC14

)

⾃動インベントリ収集

l エージェントレス型l nmap, snmp, ssh, WMIによる、Linux/Windows/NW機器の情報収集


プロビジョニング⾃動化例

サーバ構築依頼受付

変更依頼チケット発⾏

影響調査

変更承認作業指⽰サーバ構築

構築検証

監視設定作業結果承認

CMDB登録


チケットクローズ

ヒヤリングシート


インシデント対応⾃動化例

アラート発報受付チケット発⾏

影響調査

変更承認作業指⽰バージョンアップ

構築検証作業結果承認

⼀次切り分け変更依頼

CMDB登録


チケットクローズ


ヒヤリングシート例


Githubで公開中

https://github.com/oss-laboratries/OpenPIE

参考資料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


site reliability engineering (sre)を可能にするopenpieのご紹介

Technology