Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
SRE の教訓 : Google におけるインシデント管理とは
2017年3月30日木曜日
Google で何かおかしなことが起こったらどうなるか、考えたことはありますか? この業界は面白い比喩を使うのが好きで、何か起こった際に対処することを「火消し」と呼んだりします。
上の写真に写っている実際の消防士の場合とは異なり、Google で起こった事故で生命の危険にさらされることは通常はありません。つまり完璧な比喩にはなっていないのですが、Google の Site Reliability Engineer(SRE : サイト信頼性エンジニア)の 1 次対応は、他の分野での 1 次対応と共通点が多いのです。
他分野での 1 次対応と同様、Google の SRE は定期的に緊急時対応の訓練を行い、迅速かつ効率的に目の前の問題が解決できるよう、スキルやツール、テクニック、態度に磨きをかけます。
緊急時のサービス対応チームおよび Google では、何かが起こったときのことを「インシデント」と呼んでいます。
このブログ記事では、Google の SRE として私が初めて経験したインシデントについてお話しします。
プロローグ : 準備段階
過去数か月にわたり、私は
Google Compute Engine
の SRE チームとして
Mission Control
(SRE の体験プログラム)に参加していました。一般的な SRE トレーニングを 1 週間受け、Compute Engine に関するチーム メンバー同士のトレーニング セッションを毎週受けたり、プロジェクトを担当したりして学んでいきました。
私は毎週 “
Wheel of Misfortune
”(不運のルーレット)というセッションに参加し、オンコール担当者が体験する典型的な問題を与えられ、その解決に取り組みました。また、実際のオンコール担当者と一緒に対応の手助けもしました。第 2 オンコール担当者となって、第 1 担当者が受けた緊急の問題を支援したり、さほど緊急でない問題には 1 人で対処したりしていたのです。
すべての準備が整えば、いつかは最前線に立たなくてはなりません。第 1 オンコール担当者となり、1 次対応者となるわけです。
編集部注 : 書籍『
Site Reliability Engineering
』の第 28 章 “Accelerating SREs to On-Call and Beyond”(オンコール対応と、さらにその先まで対応できる SRE になるには)には、新人の SRE が 1 次対応をこなせるようになるまでの Google での育成方法が詳しく書かれています。
オンコール担当者になるということ
SRE の仕事は、単にオンコール担当者になることだけではありません。オンコールは意図的に SRE の仕事のほんの一部にしかならないようになっていますが、とても重要な仕事です。何か起こったときに誰かが対応する必要があるからという理由はもちろんですが、オンコールを経験することが SRE の他の仕事にも役に立つのです。
私が初めてオンコールのシフトを担当したときは、警告システムに 2 回ページされたこと
1
に加え、他の問題が 2 件も私のところまでエスカレーションされました。
呼び出しがあるごとに、私はアドレナリンが出るのを感じました。「きちんと対応できるだろうか? もしできなかったらどうしよう」とも考えました。でも、私は訓練のとおりに目の前にある問題に取りかかりました。すべてを知っている必要はないということを思い出したのです。他の人に聞けば誰かが答えてくれます。私は担当者ではありますが、1 人ではなかったのです。
編集部注 : 書籍『
Site Reliability Engineering
』の第 11 章 “Being On-Call”(オンコール担当者とは)には、オンコール担当者としての仕事を長期間にわたって効率的にこなすためのさまざまなアドバイスが書かれています。
インシデント発生!
呼び出された内容のうち、3 件は大したものではありませんでした。残り 1 件は少し、何と言っていいのか …… 興味深い(?)ものでした。
自分の担当するサービスで Compute Engine を利用していた Google のエンジニアが、テストの自動化に失敗し、調査の結果、少し変なインスタンスがあることに気づきました。そこで、開発チームの第 1 オンコール担当だった Parya に連絡し、彼女が私にも連絡してきたのです。
私は、より経験のある第 2 担当の Benson にも声をかけ、この 3 人と開発チームの関係者で調査を始めました。起こっていることが真の問題であると把握するまでに、そう時間はかかりませんでした。この問題を報告してきた内部ユーザーだけが影響を受けているとは思えなかったので、私たちはこれをインシデントと見なしました。
インシデントと見なすというのは、どういうことでしょうか。基本的には、その問題の影響や範囲、複雑さがある程度大きい可能性があるため、きちんとした担当者らが協力して効率的に対処する必要があるということです。
ちなみに、
Google Cloud Status Dashboard のまとめページ
に書かれていることは、すべて Google の誰かがある時点でインシデントと見なしたものです。実務的な話をすると、Google では内部インシデント管理ツールに新しいインシデントの項目を作成したときに、それをインシデントと見なしています。
オンコール担当者としての訓練を受けた際、私は Google のインシデント管理手順の原則に従い、インシデント対応を支援する内部ツールを使用しました。インシデント管理手順には関係者の役割や責任が定義されています。この投稿の最初の部分で、私は Google の SRE と他の分野の 1 次対応には共通点が多いと書きました。驚くことではないのですが、Google のインシデント管理の工程は、他の分野の緊急対応で使われている確立された
インシデント指揮手順
を参考にしているため、両者は似ているのです。
私の役割はインシデント指揮官でした。問題をインシデントと見なしてから 7 分も経たないうちに、サポート チームのメンバーが外部コミュニケーション担当となりました。
このインシデントにおいては他の役割をあてがうことはしませんでしたが、今にして思えば、Parya がオペレーション リーダーだったと言えます。彼女は、必要に応じて他の人を呼び込むなどして、根本的原因の追究に力を発揮しました。
また、Benson はインシデント指揮官のアシスタントだったと言えるでしょう。私は「こうやって、こうやって、こうすればいいと思うんだけど、これでいいと思う?」といった感じで、さまざまな質問を彼に投げかけていたからです。
効率的なインシデント対応のカギの 1 つとなるのは、インシデント対応者と、インシデントの影響を受ける可能性がある人とが明確なコミュニケーションをとることです。そのコミュニケーションは、インシデント管理ツールでも行われます。インシデント管理ツールは、Google 担当者が Google のサービスで起こっているインシデントについて知ることができる中心的な存在になっています。
また同ツールは、詳細が書かれた問題追跡データベースや、インシデント対応の調整に使われているコミュニケーション チャネルなど、Google 担当者に関連リソースも提供します。
編集部注 : 書籍『
Site Reliability Engineering
』の第 12 章、13 章、14 章は、効率的なトラブルシューティング、緊急対応、インシデント管理について書かれています。
SRE の火消しツールはロールバック機能
一部のメンバーが問題の範囲を把握しようとする一方で、他のメンバーはインシデントの解決に向けたアクションがとれるよう、問題の近因や根本的原因を探っていました。問題の範囲はある程度限られていることがわかり、原因については公開リリースに含まれていた、ある変更が元となっていることがわかりました。
これはよくあることです。稼働中のシステムにおける問題の多くは、新しい設定やバイナリ、そしてそれらの実行に必要なサービスに対して何か変更を加えることによって起こります。
こうしたよくある状況において役に立つベスト プラクティスが 2 つあります。
1 つは、緊急でない変更は徐々に行うべきだということです。簡単に言うと、すべて同時に変更しないようにするのです。こうすることで、今回のように多くのお客様に影響が出るような大問題に発展する前に、問題に気づく時間が生まれたりします。
もう 1 つは、公開するにあたっては、しっかりと理解され、きちんとテストされているロールバック機能が必要だということです。つまり、どの変更によって問題が起こっているのかが判明したときに、サービスを修復する「取り消し」ボタンが必要なのです。
徐々に公開して問題を最小限に抑え、信頼できるロールバック機能で迅速に問題に対処することこそ、サービス レベル目標(SLO)を追求するうえで非常に強力な 2 つのツールとなります。
今回のインシデントも、このパターンに当てはまります。問題が小さいうちに把握し、ロールバックによって迅速に「火消し」することができたからです。
編集部注 : 書籍『
Site Reliability Engineering
』の付録 B “A Collection of Best Practices for Production Services”(稼働中のサービスにおけるベスト プラクティス集)には、ここで触れたベスト プラクティスやその他のベスト プラクティスの詳細が書かれています。
エピローグ : 事後分析
ロールバックが完了し、問題が収まった時点で、私はインシデントを「クローズ」しました。この時点でインシデント管理ツールが、インシデント対応者が共同で作業できるように、事後分析のドキュメントを作成してくれます。消防士の比喩を使って論理的に表現すると、これは消防署長が火事やその対応を分析し、今後似たような火事が発生しないためにはどうすればいいのか、より効果的に対処する方法はあるのかということを検討することに似ています。
Google には、誰も責めることなく事後分析を行うカルチャーがあります。何かおかしなことが起こっても、そのことで誰かを責めたり罰したりしてはいけないと考えているのです。今回の物語に登場した人たちも、みな善意から何かを手がけており、インシデントの発生時点で手元にある情報を駆使して、できる限りのことをやっています。
耐久性のある変更を行いつつ、今後似たような問題を起こさないためには、システムやツール、人に関するプロセスの改善方法を見いだし、同じことが決して起こらないようにしなくてはなりません。
インシデントの影響は限られており、バグの性質も大したものではありませんでしたが、事後分析によって今後問題を避けたり、同じ問題が起こった際に早期に発見して解決したりするには、補足のアクションが 9 つ必要であることがわかりました。この 9 つの課題は、担当者を割り当てたうえで、すべてバグ追跡データベースにファイルされました。これで今後もこの問題が考慮され、研究や追跡が行われるはずです。
事後分析からわかったことは、補足のアクションだけではありません。Google では、すべてのインシデントで事後分析を行い、事後分析ドキュメントには共通のテンプレートを使用します。そのため、
全般的なトレンドを分析すること
も可能です。Google で発生したインシデントの大半が設定の変更によるものだったことが判明したのも、このためなのです(誰かが「ちょっと設定を変更するだけじゃないか」と言って、連休前の金曜日に変更を実施しようと言い出したら、このことを思い出してください)。
事後分析は関連チームにも共有されます。たとえば Compute Engine チームの場合、インシデント レビューに関するミーティングを毎週実施し、多くの SRE 担当者や Compute Engine の開発者に対してインシデント対応者が事後分析を発表します。
こうすることで、見過ごす可能性のある補足事項が確認できるほか、幅広いチーム メンバーとの間で教訓を共有でき、事例研究で信頼性について深く考えられるようになります。これは、誰も責めることなく事後分析する Google のカルチャーを浸透させる方法でもあります。
あるとき、このミーティングで、問題の責任は自分にあるといったような事後分析をする人がいたのですが、ミーティングの司会者は「自分が犠牲になろうとする気持ちは有り難いのですが、ここではそんなことはしないんですよ」と教えていました。
Google のステータスを示すページに「Google はこの問題に関する内部調査を実施し、問題の再発防止に向け、また問題を最小限にとどめるため、システムを適切に改善します」と書かれているのを目にしたときは、今回の話を思い出してください。Google でのインシデント対応を第 1 担当者として経験した私が言うのですから、この言葉が表面的な約束でないことはわかっていただけると思います。
編集部注 : 書籍『
Site Reliability Engineering
』の第 15 章 “Postmortem Culture: Learning from Failure”(事後分析カルチャー : 学びと失敗)には、事後分析カルチャーの詳細が書かれています。
1)今では呼び出しの際にページャーを使うことはないのですが、どんなデバイスやコミュニケーション方法を使っていても、いまだに呼び出しのことを「ページする」と言ってしまいます。
* この投稿は米国時間 2 月 27 日、Incident Commander である Paul Newson によって投稿されたもの(投稿は
こちら
)の抄訳です。
- By Paul Newson, Incident Commander
0 件のコメント :
コメントを投稿
12 か月間のトライアル
300 ドル相当が無料になるトライアルで、あらゆる GCP プロダクトをお試しいただけます。
Labels
.NET
.NET Core
.NET Core ランタイム
.NET Foundation
#gc-inside
#GoogleCloudSummit
#GoogleNext18
#inevitableja
Access Management
Access Transparency
Advanced Solutions Lab
AI
AI Hub
AlphaGo
Ansible
Anvato
Apache Beam
Apache Maven
Apache Spark
API
Apigee
APIs Explore
App Engine
App Engine Flex
App Engine flexible
AppArmor
AppEngine
AppScale
AprilFool
AR
Artifactory
ASL
ASP.NET
ASP.NET Core
Attunity
AutoML Vision
AWS
Big Data
BigQuery
BigQuery Data Transfer Service
Billing Alerts
Bime by Zendesk
Bitbucket
Borg
BOSH Google CPI
Bower
bq_sushi
BreezoMeter
BYOSL
Capacitor
Chromium OS
Client Libraries
Cloud API
Cloud Armor
Cloud Audit Logging
Cloud AutoML
Cloud Bigtable
Cloud Billing Catalog API
Cloud Billing reports
Cloud CDN
Cloud Client Libraries
Cloud Console
Cloud Consoleアプリ
Cloud Container Builder
Cloud Dataflow
Cloud Dataflow SDK
Cloud Datalab
Cloud Dataprep
Cloud Dataproc
Cloud Datastore
Cloud Debugger
Cloud Deployment Manager
Cloud Endpoints
Cloud Foundry
Cloud Foundry Foundation
Cloud Functions
Cloud Healthcare API
Cloud IAM
Cloud IAP
Cloud Identity
Cloud IoT Core
Cloud Jobs API
Cloud KMS
Cloud Launcher
Cloud Load Balancing
Cloud Machine Learning
Cloud Memorystore
Cloud Memorystore for Redis
Cloud monitoring
Cloud NAT
Cloud Natural Language API
Cloud Networking
Cloud OnAir
Cloud OnBoard
cloud Pub/Sub
Cloud Resource Manager
Cloud Resource Manager API
Cloud SCC
Cloud SDK
Cloud SDK for Windows
Cloud Security Command Center
Cloud Services Platform
Cloud Source Repositories
Cloud Spanner
Cloud Speech API
Cloud Speech-to-Text
Cloud SQL
Cloud Storage
Cloud Storage FUSE
Cloud Tools for PowerShell
Cloud Tools PowerShell
Cloud TPU
Cloud Translation
Cloud Translation API
Cloud Virtual Network
Cloud Vision
Cloud VPC
CloudBerry Backup
CloudBerry Lab
CloudConnect
CloudEndure
Cloudflare
Cloudian
CloudML
Cluster Federation
Codefresh
Codelabs
Cohesity
Coldline
Colossus
Compute Engine
Compute user Accounts
Container Engine
Container Registry
Container-Optimized OS
Container-VM Image
Couchbase
CRE
CSEK
Customer Reliability Engineering
Data Studio
Databases
Dbvisit
DDoS
Debugger
Dedicated Interconnect
deep learning
Deployment Manager
Developer Console
Developers
DevOps
Dialogflow
Disney
DLP API
Docker
Dockerfile
Drain
Dreamel
Eclipse
Eclipse Orion
Education Grants
Elasticsearch
Elastifile
Energy Sciences Network
Error Reporting
ESNet
Evernote
FASTER
Fastly
Firebase
Firebase Analytics
Firebase Authentication
Flexible Environment
Forseti Security
G Suite
Gartner
gcloud
GCP
GCP Census
GCP 移行ガイド
GCPUG
GCP導入事例
gcsfuse
GEO
GitHub
GitLab
GKE
Go
Go 言語
Google App Engine
Google Apps
Google Certified Professional - Data Engineer
Google Cloud
Google Cloud Certification Program
Google Cloud Client Libraries
Google Cloud Console
Google Cloud Dataflow
Google Cloud Datalab
Google Cloud Datastore
Google Cloud Endpoints
Google Cloud Explorer
Google Cloud Identity and Access Management
Google Cloud INSIDE
Google Cloud INSIDE Digital
Google Cloud Interconnect
Google Cloud Launcher
Google Cloud Logging
Google Cloud Next '18 in Tokyo
Google Cloud Platform
Google Cloud Resource Manager
Google Cloud Security Scanner
Google Cloud Shell
Google Cloud SQL
Google Cloud Storage
Google Cloud Storage Nearline
Google Cloud Summit '18
Google Cloud Summit ’18
Google Cloud Tools for IntelliJ
Google Code
Google Compute Engine
Google Container Engine
Google Data Analytics
Google Data Studio
Google Date Studio
Google Deployment Manager
Google Drive
Google Earth Engine
Google Genomics
Google Kubernetes Engine
Google maps
google maps api
Google Maps APIs
Google Maps Platform
Google SafeSearch
Google Service Control
Google Sheets
Google Slides
Google Translate
Google Trust Services
Google VPC
Google マップ
Google 公認プロフェッショナル
GoogleNext18
GPU
Gradle
Grafeas
GroupBy
gRPC
HA / DR
Haskell
HEPCloud
HIPAA
Horizon
HTCondor
IaaS
IAM
IBM
IBM POWER9
icon
IERS
Improbable
INEVITABLE ja night
inevitableja
InShorts
Intel
IntelliJ
Internal Load Balancing
Internet2
IoT
Issue Tracker
Java
Jenkins
JFrog
JFrog Artifactory SaaS
Jupiter
Jupyter
Kayenta
Khan Academy
Knative
Komprise
kubefed
Kubeflow Pipelines
Kubernetes
KVM
Landsat
load shedding
Local SSD
Logging
Looker
Machine Learning
Magenta
Managed Instance Group
Managed Instance Group Updater
Maps API
Maps-sensei
Mapsコーナー
Maven
Maxon Cinema 4D
MightyTV
Mission Control
MongoDB
MQTT
MySQL
Nearline
Network Time Protocol
Networking
neural networks
Next
Node
NoSQL
NTP
NuGet パッケージ
OCP
OLDISM
Open Compute Project
OpenCAPI
OpenCAPI Consortium
OpenShift Dedicated
Orbitera
Organization
Orion
Osaka
Paas
Panda
Particle
Partner Interconnect
Percona
Pete's Dragon
Pivotal
Pivotal Cloud Foundry
PLCN
Podcast
Pokemon GO
Pokémon GO
Poseidon
Postgre
PowerPoint
PowerShell
Protocol Buffers
Puppet
Pythian
Python
Rails
Raspberry Pi
Red Hat
Redis
Regional Managed Instance Groups
Ruby
Rust
SAP
SAP Cloud Platform
SC16
ScaleArc
Secure LDAP
Security & Identity
Sentinel-2
Service Broker
Serving Websites
Shared VPC
SideFX Houdini
SIGOPS Hall of Fame Award
Sinatra
Site Reliability Engineering
Skaffold
SLA
Slack
SLI
SLO
Slurm
Snap
Spaceknow
SpatialOS
Spinnaker
Spring
SQL Server
SRE
SSL policies
Stack Overflow
Stackdriver
Stackdriver Agent
Stackdriver APM
Stackdriver Debugger
Stackdriver Diagnostics
Stackdriver Error Reporting
Stackdriver Logging
Stackdriver Monitoring
Stackdriver Trace
Stanford
Startups
StatefulSets
Storage & Databases
StorReduce
Streak
Sureline
Sysbench
Tableau
Talend
Tensor Flow
Tensor Processing Unit
TensorFlow
Terraform
The Carousel
TPU
Trace
Transfer Appliance
Transfer Service
Translate API
Uber
Velostrata
Veritas
Video Intelligence API
Vision API
Visual Studio
Visualization
Vitess
VM
VM Image
VPC Flow Logs
VR
VSS
Waze
Weave Cloud
Webyog
Wide and Deep
Windows Server
Windows ワークロード
Wix
Worlds Adrift
Xplenty
Yellowfin
YouTube
Zaius
Zaius P9 Server
Zipkin
ZYNC Render
アーキテクチャ図
イベント
エラーバジェット
エンティティ
オンライン教育
クラウド アーキテクト
クラウド移行
ゲーム
コードラボ
コミュニティ
コンテスト
コンピューティング
サーバーレス
サポート
ジッター
ショート動画シリーズ
スタートガイド
ストレージ
セキュリティ
セミナー
ソリューション ガイド
ソリューション: メディア
データ エンジニア
データセンター
デベロッパー
パートナーシップ
ビッグデータ
ファジング
プリエンプティブル GPU
プリエンプティブル VM
フルマネージド
ヘルスケア
ホワイトペーパー
マイクロサービス
まっぷす先生
マルチクラウド
リージョン
ロード シェディング
運用管理
可用性
海底ケーブル
機械学習
金融
継続的デリバリ
月刊ニュース
資格、認定
新機能、アップデート
深層学習
深層強化学習
人気記事ランキング
内部負荷分散
認定試験
料金
Archive
2019
2
1
2018
12
11
10
9
8
7
6
5
4
3
2
1
2017
12
11
10
9
8
7
6
5
4
3
2
1
2016
12
11
10
9
8
7
6
5
4
3
2
1
2015
12
11
10
9
8
7
6
5
4
3
2
1
2014
12
11
10
9
8
6
5
4
3
2
Feed
月刊ニュースレターに
登録
新着ポストをメールで受け取る
Google
on
Follow @GoogleCloud_jp
0 件のコメント :
コメントを投稿