あわてない技術

火事場が得意、とは全く言わないのですが、割と「〇時までに何をどういう順番で必達」みたいなギリギリのシチュエーションをどうのこうのする仕事は「好き」です。どういう心持ちを持ってその状況に臨んでいるかをなんとなく見える化してみたく書きました。我流ですが…

まず、人間一人ですべてを解決するなんて到底無理です。まとめてみるといわゆる普段の技術的な知識の深さとはかなり異なるところで求められるものがある気がしています。


## 先に結論

「すべきことはすべてやってるし…」と唱える
、と、たぶんあわてない。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/93824/41c8e6ed-ed9a-b91b-48d5-20afc1097b5b.png)


SRE 本を引用しつつ並べております。
参考: [Google - Site Reliability Engineering](https://sre.google/sre-book/table-of-contents/)


## ふりかえる

いきなり何をという感じだが、過去に「あわてる」経験くらいはあります。その時のことをふりかえっておきます。

- 日ごろから慣れる。
- 不明点をなくしておく。
- [Google - Site Reliability Engineering](https://sre.google/sre-book/being-on-call/) オンコールの章に学びが深いので、以下まとめつつ引用。


> - 近年の研究によると困難に直面したときに人が選択する考え方には2つ
>     - 直感的かつ反射的に即行動しようとする。
>     - 理性的かつ集中を保ち、慎重な認識を働かせようとする。
> - **複雑なシステムのサービス障害を扱う場合は後者の選択肢の方が良い結果をもたらしやすく、十分に計画した上でインシデントを処理していける**

> - 適切な精神的枠組みの中にエンジニアがいられるようにするためには、オンコール担当であることにまつわるストレスを減らすことが重要
> - ストレスホルモンは、認知機能を損なったり、最適ではない判断を下す要因となる影響を行動に及ぼすことが知られており、これには恐怖感も含まれる

> - インシデント管理の過程では直感的で素早いリアクションが望ましい性質のように思われることもあるが、それらには欠点がある。直感は間違いであることもあり、明確なデータの裏付けを取りにくい。直感に従うということは、そもそも出発点から間違っていた論理の道筋を追いかけさせてしまい、エンジニアの時間を浪費することにつながる。
> - データが揃った時点で望ましいペースで手順を踏むことと、並行してその推定を批判的に検証することの間で完全なバランスをとるようにすること。

> - **重要なのは、オンコールを担当するという負担を思ったよりも軽いものにしてくれるようなリソースがあり、それらを頼りにできる、とオンコールの SRE が理解すること。** 以下など
>     - 明確なエスカレーションパス
>     - しっかりと規定されたインシデント管理の手順
>     - 非難を伴わないポストモーテム文化

- つまり意外と怖くない、と自分で自分に言い聞かせておく。

> - **インシデントが発生したときには、何がうまくいかなかったのかを評価し、うまくいったことを認識し、同じエラーが将来繰り返されないようにすることが重要。**
> - SREチームは重大なインシデントの後にはポストモーテムを書き、生じたイベントの完全なタイムラインを詳細に記録しなければならない。
> - 人ではなくイベントに焦点を当てる。個人を非難することからではなく、プロダクション環境で起きたインシデントのシステム的な分析を行う。
> - ミスは起こるものであり、ソフトウェアはなるべくそういったミスが起こらないようにするべき。自動化を行うことは、人間によるエラーを避けるための最良の方法の一つである。

- うまくいったこともふりかえっておく。


## 装備する

気持ちが整ったところで、ヒノキの棒から整えます。

- 携帯電話の充電
- 安定環境の確保
- 時間の確保
- 電話等に出る際の応答スクリプト
- 最低限取得する客観的事実収集のための常備テンプレート 

```
- 確認事項
- 確認手段
- 時刻
    - etc...
```

## 想定する

電話が鳴る (こともある) 前提で想定しておきます。

- 行動手順
- 連絡先
- 〇〇 に 〇 分所要など、掌握、見積もり

## 気を落ち着かせる

「やるべきことは準備済み」となれば、あとは落ち着くしかないです。リラックスに専念します。

### 深呼吸をする
- どうせ来るときは来るので、深呼吸します。お茶を飲むも良し。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/93824/c6be3313-0305-8a4a-44fb-7bf9cbd79591.png)
参考: [ほぼ日の「おちつけ」 - ほぼ日刊イトイ新聞](https://www.1101.com/store/ochitsuke/goods/index.html)



### できることを書き出してみる

ここからは「来た」ときの話。基本的な情報収集をしたとして以下など。

#### 細かくする
- いま「自分が」調べられることを切り分ける。
- いつまでにこれをやれば OK というチェックポイントを設ける。

#### もっと細かくする
- 相談して人に分担できるようにする。協力者を確保する。
- 1 人じゃなくなったらもう安心。

### 運動してみる
- 体をほぐす。
- 体を温める。

## 捨てる

ここまできたら、普段からやっておくべきこと。

### スマホを置く
- お風呂に入る。
- 寝る。
### アンインストールする
- 要らんものを平時に整理整頓しておく。環境が安定するようにしておく。

## 腹をくくる
- 来るときは来る。
- 建設的に考える [Google - Site Reliability Engineering](https://sre.google/sre-book/postmortem-culture/) ポストモーテムの文化 再掲
> - 指弾の例「この複雑なバックエンドシステムは丸ごと書き直すべきだ！　この3四半期の間、毎週トラブルが起きているし、次から次へと修正するのにはもううんざりじゃないか？　本気で言うけど、次にページを受けたら自分で書き直すことにするよ」
> - **非難のない例「バックエンド全体を書き換えるというアクションで、面倒が発生し続けるのを止めることができるかもしれない。このバージョンのメンテナンスマニュアルはとても長くて、それに従って完全なトレーニングをするのは本当に難しい。きっと将来のオンコール担当からも感謝されることになるよ」**

- 寝る [Google - Site Reliability Engineering](https://sre.google/sre-book/data-integrity/)
> - **おかしくならないものはない、だけではなく、どんなものもいつかはおかしくなるということを認識できれば、本物の緊急事態に対して備える大きな一歩になる。起こりうる災厄と、それぞれの災厄に対応する計画があれば、少なくともしっかりと眠れる。**



以上、書き出してみると、突発的に人間ひとりができることなんてもともと大したことはないです。それはイコール「すべきことはすべてやった…」と、暗示して、弱い自分と向き合うことなんじゃないだろうかとか、おもったりします。あわてないエンジニア生活を送りたいですね…


## 参考
- [Google - Site Reliability Engineering](https://sre.google/sre-book/being-on-call/)
- [AwesomeなSRE読み物集 - SRE Resources「On call」の章を中心に #GitHub - Qiita](https://qiita.com/e99h2121/items/ae338e099f2ba765aed4)
- [障害対応で大切だと感じていることのまとめ #障害対応 - Qiita](https://qiita.com/gengen0719/items/b8b628dce0522c78f0d6)
- [自他に「対抗する」テクニカルサポートの目次 #ポエム - Qiita](https://qiita.com/e99h2121/items/2b1aa533c89394ddc994)

以上です～