学習環境では、壊しても作り直せば済みました。ところが本番では、何を自分で決めてよく、何は聞くべきなのかが分かりません。手順書を読むだけの日が続くと、「このままで大丈夫か」と不安にもなります。この記事は、運用・保守の職に就いた最初の期間を3つの段に分けて、各段で何をして何を聞くかを整理します。
この記事の結論
- 最初の期間の仕事は「速く直すこと」ではなく、「安全に手順を踏める人になること」です。
- 順番は、環境を読む（見る）→ 手順書どおりに変更する（真似る）→ 障害の一次対応を任される（任される）です。
- 手順書は読むだけでなく、古い箇所を見つけて直す提案まで出すと、信頼が早く積み上がります。
- 判断に迷う基準は「戻せるか」「影響範囲が分かるか」の2つ。どちらかが怪しければ聞きます。
- 毎週の振り返りで詰まった所を記録しておくと、次の段へ上がる根拠になります。
最初の期間に求められるのは何か？
運用の最初の期間に求められるのは、速さではなく「手順を守って安全に動く」ことです。本番の環境は、すでに誰かが使っています。新人が一番やってはいけないのは、よかれと思って動かして影響を出すことです。
AWS の Well-Architected フレームワークには、6本の柱の1つに運用上の優秀性があります。この柱は、ワークロードの設計・提供・保守のベストプラクティスを扱い、運用を開発と切り離された別機能にしないという考え方です。運用の人は「決まった作業をこなす係」ではなく、システムを良い状態に保ち続ける仕事の一部を担っている、と読めます。
同じ柱の「準備」の考え方には、頻繁で小さく、戻せる変更にすること、失敗する変更にあらかじめ備えること、日常作業の runbook（手順書）と障害対応の playbook を持つことが挙がっています。新人の最初の期間は、この準備の仕組みを使う側として慣れていく時期にあたります。
SEE, COPY, OWN最初の期間を3段で
最初の期間は見る → 真似る → 任されるの順で回す
-
見る
構成図・監視・チケットの履歴で環境を読む
-
真似る
手順書どおりに変更作業を出す
-
任される
障害の一次対応で、直すか渡すかを決める
3つの段の中身を、先に表で並べます。
| 段 | やること | 聞くこと |
|---|---|---|
| 見る | 構成図・監視・チケットの履歴で環境を読む | 見て分からない用語と、触ってはいけない所 |
| 真似る | 手順書どおりに変更作業を出す | 事前確認の範囲と、戻し方 |
| 任される | 障害の一次対応で、自分で直すか人に渡すかを決める | 判断に迷った時点で、影響範囲と戻せるか |
CHECK 1ここまでの確認
運用の仕事を始めた最初の期間に、まず優先されるのはどれ?
答えと解説
答え: 2. 手順を守って安全に動くこと
本番では速さより「影響を出さない」信頼が先に求められます。第1章の「速さより安全に手順を踏む」を読み直してください。
見る段：環境と手順書をどう読むか
最初にやるのは、触らずに読むことです。読む対象は3つあります。
- 構成図：どんな部品がどうつながっているか。分からない箱は、そのまま付箋にして先輩に聞きます。
- 監視：普段のグラフとアラームの状態。平常時の姿を知らないと、異常に気づけません。
- チケットの履歴：過去にどんな問い合わせや障害があり、どう片づけたか。運用の「あるある」はここに溜まっています。
手順書は、書いてある順に読むだけでなく、「なぜこの順番なのか」「この確認は何を防ぐためか」を考えながら読みます。理由が分からない行は、聞く材料です。分からないまま実行すると、手順が崩れたときに自分で判断できません。
この段の目標は、「平常時の状態を説明できる」ことです。平常を知っていれば、異常に気づいたときに「いつもと違う」と言えます。
真似る段：変更作業を手順書どおりに出す流れ
次の段では、手順書どおりに変更作業を実施します。変更は、事前確認・実施・事後確認・戻し方の用意の4ステップで考えると崩れにくくなります。
変更作業の4ステップ
変更は戻し方まで用意して初めて実施できる
-
事前確認
対象・時間・手順書・連絡
-
実施
手順書の順番どおりに1つずつ
-
事後確認
反映と監視の平常化を見る
-
戻し方の用意
失敗時の戻し方を先に決める
- 事前確認：対象は合っているか、今は実施してよい時間か、手順書は最新か、影響する相手に連絡が済んでいるか。
- 実施：手順書の順番どおりに、1つずつ進めます。自己流の省略や追加はしません。
- 事後確認：変更が反映され、監視が平常に戻っているか。「実行できた」だけで終わらせません。
- 戻し方の用意：失敗したらどうやって元に戻すか。実施の前に決めておきます。
4つのうち、新人が飛ばしやすいのは戻し方です。戻せる変更なら、失敗しても被害が限られます。Well-Architected の準備の考え方が「小さく、戻せる変更」を勧めているのも同じ理由です。戻し方が書かれていない変更は、実施せずに先輩へ聞くのが安全です。
CHECK 2ここまでの確認
変更作業を実施する前に、用意しておくべきものはどれ?
答えと解説
答え: 2. 失敗したときに元へ戻す方法
戻せることが、実施してよい条件になるためです。第3章の4ステップのうち「戻し方の用意」を読み直してください。
任される段：障害の一次対応で「自分で直す」「人に渡す」の境目
手順どおりの変更に慣れると、障害の一次対応を任されるようになります。ここで大事なのは、全部を自分で直そうとしないことです。一次対応の役目は、状況を整理して、直すか、渡すかを正しく決めることです。
境目は2つの問いで決めます。
迷ったときの2問
戻せるか・影響範囲が分かるかで動き方を決める
-
1.戻せる、かつ範囲が分かる
手順書の範囲で自分で進める
-
2.どちらかが怪しい
進める前に分かる人へ聞く
-
3.どちらも分からない
触らずに人に渡す
| 戻せるか | 影響範囲が分かるか | 動き方 |
|---|---|---|
| 戻せる | 分かる | 手順書の範囲で自分で進める |
| 戻せる | 怪しい | 進める前に、分かる人に確認する |
| 戻せない・怪しい | 分かる | 実施の前に、決める人へ相談する |
| 戻せない・怪しい | 分からない | 触らずに人に渡す（エスカレーションする） |
人に渡すときは、見えている事実だけを伝えます。いつから、何が、どの範囲で起きているか、すでに何を確認したか、まだ触っていないこと。推測と事実を分けて伝えると、受け取る側が動きやすくなります。
アラームが鳴ったときの最初の切り分け方は、別の記事にまとめてあります。この記事では繰り返しません。
READ ALSO — 学習中向け・段2 構成
アラームが鳴ったときの初動｜いつから・どこで・何が変わったかを切り分ける順番
CHECK 3ここまでの確認
影響範囲が分からない障害に出会ったとき、まず取る行動はどれ?
答えと解説
答え: 2. 状況を整理して、分かる人に渡す
分からないまま触ると被害が広がるためです。第4章の「戻せるか・影響範囲が分かるか」の2問を読み直してください。
手順書が古いときはどうするか？
運用を始めると、手順書と実際の画面や構成が食い違う場面に出会います。これは新人が最も貢献しやすいところです。まっさらな目で読んでいるので、古い箇所に気づけます。
動き方は3つです。
- 作業の前に聞く：食い違いを見つけたら、手順書どおりに進めず、先輩に確認します。
- 実際に通った手順を控える：確認して進めた内容を、メモに残します。
- 作業のあとで、直す提案を出す：どこが、何から何に変わっているかを、短く書いて渡します。
勝手に書き換えず、提案の形にするのがポイントです。手順書は、チームの全員が同じ前提で動くための約束です。1人が黙って変えると、約束が崩れます。提案なら、レビューを通して全員の手順になります。
毎週の振り返りで次の段に進む根拠を作る
3つの段は、気づいたら上がっているものではありません。1週間の終わりに、短い振り返りを書くと、上がる根拠が溜まります。
- 今週、手順どおりにできたこと
- 詰まったところと、どう解いたか（聞いた相手と答え）
- 分からないまま残っていること
- 手順書で見つけた、古い箇所や分かりにくい箇所
この記録は、先輩や上司と話すときの材料にもなります。「ここまでは1人で進められる」と具体的に示せれば、任される範囲の相談がしやすくなります。同じ所で何度も詰まるなら、そこが次に学ぶ題材です。障害が起きたあとに原因を探る型は、ポストモーテムの記事が参考になります。
READ ALSO — 実務向け・段3 基盤
ポストモーテムとは何か｜障害のあとに「誰のせいか」ではなく「なぜ起きたか」を残す振り返りの型
つまずいたときの直し方
聞くタイミングと聞き方で、つまずきの多くは軽くなります。
- 聞くタイミング：「戻せるか」「影響範囲が分かるか」のどちらかが怪しくなった時点です。自分で調べる時間を決めておき、それを過ぎたら聞きます。
- 聞き方：何をしようとしていて、どこまで確認し、何が分からないのかを、1〜2文で伝えます。「できません」ではなく「ここまで確認した。ここが分からない」と言うと、答えが早く返ってきます。
- 聞いたあと：答えを手順書や自分のメモに残します。同じ質問を繰り返さないことが、信頼につながります。
運用は、環境と障害の全体を見られる仕事です。回し方次第で、設計の前提を学ぶ入口にもなります。
Cloudory 執筆者（AWS 認定 全冠）
最初の期間は、できることを増やすより、「この人なら任せても影響を出さない」と思われる積み重ねが大切です。聞くことを恐れず、聞いた内容を残してください。
参照ソース
- AWS Well-Architected Framework 運用上の優秀性の柱（Welcome） — 運用上の優秀性が、設計・提供・保守のベストプラクティスを扱い、運用を開発から切り離さない考え方であることの根拠
- AWS Well-Architected Framework 運用上の優秀性の柱（準備） — 小さく戻せる変更、失敗への備え、runbook と playbook を持つことの根拠
