-: 07/13/19

まえがき

人生は色々あるので365日24時間会社のサービスのオンコールを受け続けないといけない事も時にはあります。

そうした状況で色々と安心してひとりインフラをやっていく為のノウハウが自分の中に溜まってきたので、ここにガイドとしてワーッと書いちゃおうと思います。

もちろんサービス構成によってはそうはいかない面も多々あるとは思いますが、あくまで一例として参考にしてもらえればと思います。

前提条件

インフラ
- AWS
通知系
- Sentry
- Datadog
- PagerDuty

という環境ではありますが、PagerDuty を利用されている方々であればおおよそ誰でも該当するような内容かなと思います。

装備品

必須アイテム

スマートフォン📱
- PagerDuty からの障害通知を受け取ったり、障害アナウンスや対応依頼等の連絡に用いる必須アイテムです
- 必ず常に持ち歩きましょう
- 振動に気付けるような場所に(服のポケット等)入れておくと速やかに通知に気付けます
  - Android であれば PagerDutyのアプリの設定でサイレントモードを無視して音を鳴らす事も可能です
- バッテリー切れにならないように日頃から運用に気を払いましょう
- Datadog, PagerDuty, AWS マネジメントコンソール、あるいは1Password などの、監視・インフラ系・認証情報系のサービスにいつでもログイン出来る環境を整備しておくと良いでしょう。
- バッテリーの容量が大きい端末を選択すると良いでしょう。
社用ラップトップ 💻
- 障害対応で手を動かすために必須です
- 基本的には365日24時間常に持ち歩きましょう
  - MacBookPro を常に持ち歩くのは想像以上に大変です。必要に応じて、普段の開発用の端末とは別に、MacBookAir などの1kgちょっとの軽量なラップトップを(個人か会社かはわかりませんが)用意し、障害対応用に持ち歩くのは良いアイデアです。
    - その場合は、対応に必要な認証情報にアクセスできる状態を維持しておく必要があります(1Password のトークンがわからずに認証情報にアクセスできない、という状況は最悪です！)。
  - ラップトップを持ち歩きたくないシチュエーションもあります（クラブでガン踊る時や、いつひったくりに合うかわからない場所を歩かなくてはならない場合など）。
    - そのような場合は短時間で端末を回収できる安全な場所（コインロッカーなど）に保管し、スマートフォンを持ち歩くようにするべきです。
カバン 🎒
- 365日常に端末を持ち歩く必要があるので、完全防水のカバンを用いるようにしましょう。リュックだと腕への負荷を軽減することが可能です。
  - 前述の通り、ラップトップの重量の問題は軽視出来ない問題です。ビジネス向けよりもアウトドア向けの、軽量かつ身体に負荷がかかりにくい素材のものをおすすめします。

推奨される日常的な行動

手元に届く通知を最適化する
- 基本的にすべての通知はスマートフォンで受け止めることになります。インストールしているアプリ等の通知は、本当に必要なものだけに絞るように調整しましょう。
  - メール通知は重要です。PagerDuty 経由でなくとも、各種ベンダーからの重要な通知はだいたいメールで飛んできます。そんな中、たとえば「体調悪いんで今日休みます」みたいなメールの通知に混じって障害アラートの通知が飛んでいると、本当に重要な通知に気づくことが出来ません。メールフィルタは丁寧に育て上げましょう。
  - スマートフォンへの通知はほぼバイブレーションで気付くことになります。不要な趣味アプリの通知などは可能な限り削りましょう。おすすめのコスメの通知などは必要ありませんよね？ソシャゲのイベント開始の通知は時には重要になるかもしれません。必要に応じて調整する必要があります。
障害通知が届いた時に何かしらの手段で確実に気付くことが出来る状態を常に保つ
-「気付けませんでした」が最悪なので、まずは絶対に気付ける状況を作りましょう。スマホを常に持ち歩くのは必要があります。
- スマートウォッチが震えてくれれば起床出来る可能性がありますが、理想を言えば家のスマートスピーカーがアラートを通知してくれるので起床出来る、という状態を目指したいところではあります。
  - 本当の理想の形は、誰かが気付けなくても他の人が気付ける、という状態です。
可能な限り速やかに問題対応に取り掛かれる状況を常に作る
- 少なくとも障害アラートを Acknowledge してから10分以内にはラップトップを回収して作業できるようにするのが理想です。
最悪自分が動けない場合に誰かを呼び出してなんとか出来るようにする
- 色々な事情があり、自分で動くことが出来ないシチュエーションもあります。例えば新幹線の中で電波が途切れがちなので他の人に作業を依頼するとか、自分には権限がなくて、上の人を経由しないと対応できないものなどです。問題の重要度によりますが、必要に応じて Slack で鬼リプライを飛ばすなり、最悪直接電話をかけるなりして、誰かを動かす必要があります。
  - そのためには非常時の緊急連絡網をちゃんと整備しておく必要があります。休日は Slack は見ないという主義の人もいるので、電話番号一覧を社内に用意するのが最低ラインかなと思います。
    - が、それも面倒なので入手できる権限は予め入手しておく事も大事です。

避けるべき日常的な行動

WiFi が使えない飛行機、電波が繋がらなくなる可能性の高いフェリーでの移動
- その時間帯に他の人がアラートを受け取れるのであれば問題はありませんが、ひとりの場合は断念する他ないです。
なんかよくわからんけど自ら監禁・軟禁されに行くような行動
高速道路などの一時停止が行いづらい状況で、単独で車両の走行するなどの行為
- まあ最悪スマホで通知さえ受け取れたらなんとでも出来る気はしますが、そわそわと運転するのはサービス的にも運転者的にも危険です。代理ドライバーを乗せておくなりして、安心して運転できる環境を作りましょう
スマートフォンおよびラップトップの破壊
- 絶対にやめましょう
無思慮な海外旅行
- 例えば中国の場合、Google 等、金盾の影響で色々なサービスが遮断されている環境では、想定外のサービスが利用不可に見舞われる可能性があります。香港 SIM などを購入したり、事前に VPN を用意しておくなど、金盾外からインターネットにアクセスできる環境を用意する必要があります。
- インターネット環境がろくに整備されていない地域に出向いた場合、かなりの確率で詰みが発生します。旅行先のインターネット環境については入念に調査を行い、本当にそこに向かっても問題がないのか、確認を行うべきです。

業務上推奨される行為

インフラ改善
- コスト面も、セキュリティ面も、アーキテクチャ面も、今ある形が最適解とは限りません。改善していきましょう。
- 「そういえば何気なく使ってるあの社内システムって、新しいバージョン出てないんだろうか？」と日頃から疑問を抱く事は良いことです。
非常事態時のバックアップ構成およびリストア操作の把握
- バックアップが確実に取られていることを確認するのは大事ですが、リストアのオペレーションを理解することもとても大事です。GitLabとかSpotifyがちょっと前にやらかしましたね。
- 障害復旧リハーサルなどを行うことは大変有益です。他のエンジニアが知らなかったオペレーションを共有する事が出来る、というメリットもあります。
「これ本当に維持する必要ありますか？何に使ってたんですか？」って色々な人に訊く
- 本当に大事です
- なんか経緯もよくわからないし誰が使ってるのかもわからないけどとりあえず動かしておくか、みたいなものは得てして発生しがちで、ちゃんと「必要ですか？消していいですか？」と訊ねてお片付けをすると無駄なコストを払わずに済みます。
AWS や各 SaaS の請求書をじっくり読み込む
- リザーブドインスタンスやスポットリクエストの利用状況の把握や、適宜の購入は重要です
- 想定外のコスト（不正利用や、過剰使用など）が発生している事を把握できる可能性があります。余裕がある限りは請求書一式は目を通すべきです
問題を抱え込まずに適切にエスカレーションする
- インフラをひとりでやっていると、様々な問題を見つけてしまいます。その時は抱え込まずに、Issueを立てて周知するなり、オフィスで大きな声を出したりする必要があります。
  - 今は見逃してやる……系も、中くらいの声で「見逃す……！」と発言しておくと「ああなんかあったな」という意識を根付かせることが出来るので、有用です
- 本当にマズいやつを見つけた時に、エスカレーション先がわからなかった場合は深刻そうな顔してえらい人に「あの……すみません……ご相談なんですが……」言うと良いです。

業務上行ってはならない行為

個人情報や企業情報や監査ログなどのデータへの不必要なアクセス
- 見れば見るだけ罪が重くなると思ってください。
- 権限が付与されがちな立場なのでやむを得ない面も多々ありはしますが、それでもちゃんと権限に応じて見れる範囲を絞っていくべきです。
サービス提供に関する破壊的な行為
- 大いなる権限には大いなる責任が伴います。良識を持って仕事をしましょう。
よくわからないけどエイヤで変更かけようぜ的な行為
- 100％大丈夫という保証がない限りはきっちりと問題がないということのエビデンスを取ってから変更を行いましょう。
- 気軽に押したボタンでサービスダウン、ではあまりにもやりきれません。
- でも時には無断深夜デプロイが必要だったりする事もあるので、「絶対にこれでいける」という自信が170%くらいあるなら（諸説ありますが少なくとも私は）やっていいと思います。

マインド

ユーザが問題なくサービスを閲覧できる状況を維持する事に注力しましょう。
- ユーザが何気なしにありがたがってくれるのが最善です。
エンジニアの人が LGTM を出しても信用してはいけません。ねっとりと「本当か？」って言いましょう。
- 問題があれば速やかに revert して問題のない状態に戻しましょう。不運な問題を解決するのが先決です。「アイツがこれで行けるって言ったんだ！」などの糾弾は無用な諍いを生むので、とにかく復旧に専念しましょう。問題を起こした当人も何かしらの反省は自ずと抱くはずなので、さらなる修正に期待しましょう
SLO を計測することは大切です。
- ですが、100%正確な SLO を速やかに用意するのは一般に考えられているほど簡単ではありません。
- 不正確でもいいので、暫定的な SLO を用意するべきです（たとえば計画メンテ時のダウンタイムが数値に影響を与えている状態でも構いません）。これは外部に公開する必要はありません。内部的に用意して、それから少しずつ正確な SLO を出せるように行動していくようにしましょう。Datadog にも PagerDuty にもメンテナンスウィンドウという機能があるので、正確な SLO 計測に役立つはずです。やがて、外部にも公開可能な SLO が出来上がってくるはずです。

障害対応フロー

なにかしらの問題で障害アラートが鳴ったとします。
以下の順序で対応していきましょう。

アラートを元に障害の影響範囲を把握する（大体は、まあサービス利用に問題ないわ、とか、レアケースだし修正だけしてアナウンスはしないわ、みたいな対応になる）。
（アクセス不能などのように）影響範囲が広そうであれば、Slack のパブリックなチャンネル（多くの人が目を通していそうなチャンネルを選ぶべきです）等で、対外的に「障害発生中で対応中です」というアナウンスをしてもらうように依頼する。たとえば、下書きに保存すれば編集中のデータがロストせずに済む、というような状況であれば、回避策も一緒にユーザーにアナウンスするといいでしょう。それと同時に、エンジニア全員に障害情報の詳細を共有して、関連してそうな操作を行った人がいないかを確認すると良いでしょう。
障害が発生した原因について調査する。インフラエンジニア以外の人間も巻き込めるとベストです。
必要に応じて問題のコミットを Revert するなり、このアラートはどうしても起きちゃうやつだわと判断して諦めるなり、根深い部分に問題が生じてるのでオペでなんとかするなり、対応方針を固めましょう。
方針に応じた対応をする。問題のある一部のユーザよりも、大多数のユーザが問題なくサービスを利用することが出来る事を最優先すると良いでしょう。（モノによるが）一部のデータの欠損等は、全ユーザに比べたら影響が小さいので、最悪諦めるという判断をしても良いでしょう。
全ユーザに向けて復旧アナウンスをする
色々と諦めて欠損したものを、アクセスログや RDS の PITR やアクセスログ等から復旧出来ないか考慮し、復旧できそうなものはユーザに対して謝罪と復旧を行う旨を伝えて、復旧作業を行う。
個々のユーザに対して、データ復旧の告知を行う。

基本的にはこんな感じのフローが良いのかなと思います。
大切なのは、やれる限りはユーザが望んでいた状態を復旧させる為に尽力することです。

本当に大事だったこと

ひとりにインフラを負わせない

-

2019/07/13

ひとりインフラサバイバルガイド