terraform applyをより安全に実行するためにできること(postcondition編)
sho
デロイト トーマツ ウェブサービス株式会社(DWS)公式ブログ
こんにちは、下條です。名古屋は最近は雨も多くちょっと涼しくなってきました。
弊社ではお客様の運用保守を請け負っているプロジェクトが多くありますが、専任の運用チームはなく、開発など他の作業をしながら運用保守をしている状況となっています。
その状況下で、システム障害時にどのようなフローで対応しているかを整理してみました。
まずは障害のトリアージを行い、どれだけ優先して対応する必要があるかを判断します。
優先度 | 説明 | 対応方針 |
---|---|---|
超優先 | お客様に重大なビジネス影響が出ている問題が発生している場合。 | 全ての他の作業はペンディングし最優先で対応する。 |
最優先 | お客様にビジネス影響が出ている問題が発生している場合。 | 基本的に他の作業はペンディングし最優先で対応する。 |
優先 | 問題が発生しているがお客様に直接のビジネス影響がでていない場合。 | 可能な限り優先して対応する。 |
※障害ですので、最低でも優先としました。
自社で運用保守しているシステムにおいて、他社様と関連している部分もあるため、まずは原因を切り分けるのが最初のステップとなります。
なお、障害時にはお客様は不安を抱えているため、適切に一報を入れるなど心がけます。その際には以下の点に気をつけます。
例えば、DBコネクション数の急増によりサイトに繋がりづらい状態となったといった場合の一時報告例を記載してみます。あくまで架空の例です。
【現象】
2018年xx月xx日xx時xx分ごろから、サイトに繋がりづらい状態となっています。
【原因】
DBへのコネクション数が急増したことが原因と考えられますが、根本原因については調査中です。
【対処】
アプリケーションサーバの再起動で暫定的に回避できる可能性があるため、アプリケーション
サーバの再起動を実施いたします。
その上で、DBコネクション数増加の根本原因につきましては引き続き調査いたします。
以上、システム障害時の対処フローについてまとめてみました。もちろん決して障害を望んでいるわけではないですし、障害が起きにくいような設計にすることは前提としてありますが、障害対処は意外と楽しいものです。例えば以下のような楽しさがあります。
もちろんツラい部分があるのも確かですが、もしシステム障害が起きてしまったらこういう楽しみも見つけながら果敢に立ち向かっていきましょう!