(cache) Google Cloud Platform Japan 公式ブログ: SRE のサポートを受けるべきアプリとは？ : CRE が現場で学んだこと

SRE のサポートを受けるべきアプリとは？ : CRE が現場で学んだこと

2017年7月7日金曜日

編集部注 : 社内で多くのアプリケーションやサービスが稼働するようになると、SRE（や運用）チームのサポートが追いつかないケースが出てきます。今回の『CRE が現場で学んだこと』シリーズでは、企業内のアプリケーションやサービスの中で何を SRE にサポートしてもらうかを、うまく原則に基づいて防御的に決める方法について見ていきます。Q : どうすれば自社の SRE チームが限界に達しているとわかるのですか？どうすればサポートすべきアプリケーションをうまく選べるのでしょう？ SRE チームはいつアプリケーションのサポートを止めるべきなのでしょうか？SRE によるサポートの実質的な限界Q : エンジニアが 12～16 人いれば、開発チームが作成したアプリケーションすべてを確実にサポートできることになりますよね？

サービスがきちんと稼働し続けるために必要な通常の運用タスク。たとえば、リリース、バグフィックス、緊急性のないアラートやバグなどがこれに相当します。自動化することで、こうしたタスクは（なくすことはできないものの）軽減できるでしょう。

予定外で重要度の低いリクエストによる「割り込み」。これを減らそうと努力しても無駄であることがわかっています。一番効率的な対処法は、頻繁にやって来るリクエストの 50～70 % をセルフサービスツールに任せることです。

緊急アラートへの対応、インシデント管理、その後のフォローアップ。これらに割く時間を減らす一番の方法は、サービスの信頼性を高め、アラートの精度を調整することです（アラートが発動したときは、サービスで実際に起こっている問題をきちんと示すようにするとよいでしょう）。

Q : 6 週間のうち 4 週間は SRE が運用作業を行っていないことになります。その時間を使って、SRE チームがサポートするサービスの量を増やせないでしょうか？SRE のサポートに限界が来たらどうするのかQ : では、開発者に作ってもらいたいと考えている次のアプリケーションの扱いはどうしましょう？現在のアプリケーションをサポートすることで手一杯なのではないですか？どのアプリケーションをサポートするべきかQ : いい考えだと思います。つまり、ビジネスへの影響度に応じて優先順位を付ける方法が常に正しいということですよね？

モニタリングと測定基準 : たとえば、レスポンスのレイテンシ、エラー、未対応となっているクエリの率、リソースの利用率がピークに達しているかどうかなどを検知することです。

緊急対応 : 交代でオンコールに対応することや、トラフィックが落ちたことの検知、第 1 担当者や第 2 担当者およびエスカレーション、作戦を練ること、“Wheel of Misfortune”（不運のルーレット）などです。

キャパシティプランニング : 四半期ごとの予測や、突然の持続的なスパイクへの対応、稼働率向上プロジェクトの実施などです。

サービス速度の上げ下げ : さまざまな場所で稼働しているサービスの場合、（エンドユーザーのレイテンシを低減するなどの理由から）場所に応じて対応速度を上げたり下げたりするスケジュールの計画を立て、そのプロセスを自動化することでリスクや運用負荷を軽減させます。

変更管理 : カナリアリリース、1 % experiments、ローリングアップグレード、不具合発生時の迅速なロールバック、エラーバジェットの査定などです。

パフォーマンス : ストレステストや負荷テスト、リソース利用の効率性監視と最適化のことです。

データの完全性 : 再構成できないデータを、読み込み時に復元性かつ可用性の高い状態で保存しておくこと。これには、バックアップから迅速に復元できるようにすることも含まれます。

* この投稿は米国時間 6 月 23 日、Customer Reliability Engineer である Adrian Hilton によって投稿されたもの（投稿はこちら）の抄訳です。- By Adrian Hilton, Customer Reliability Engineer

Google Cloud Platform Japan Blog

SRE のサポートを受けるべきアプリとは？ : CRE が現場で学んだこと

0 件のコメント :

コメントを投稿

12 か月間のトライアル

Labels

Archive

Feed

Company-wide

製品・サービス

デベロッパー