こんにちは。インフラエンジニアの内田です。TECHSCORE に記事を書くのは約10年ぶりとなります！！よろしくお願いいたします。

さて、私の記事ではこれまで TECHSCORE ではあまり書かれることがなかったサーバー運用業務の観点から『新人エンジニアに捧ぐ！ Linux 本番環境で作業する前に確認しておきたい3つのポイント』と題してお伝えしたいと思います。

ちょうど今日は4月1日ですので、新社会人として一歩を踏み出される新人エンジニア（新卒エンジニア）の方も多いかと思います。そんな皆さんにぜひ読んでいただきたい記事です。

本番環境とは：お客様に提供しているサービスが動いているサーバーやネットワーク装置などを指しています。

確認ポイント1：手順書は準備しましたか？

我々が本番環境で作業を行うに当たって、コマンド2、3個ぐらいの簡単な作業であっても、事前に手順書を準備してから作業に臨みます。

なぜなら本番環境でコマンドを打つということは、ミスがサービス停止につながりかねないリスキーな作業であるからです。なので、きっちりと準備して作業を行うわけです。

さて、それでは例として、『Apache へのリダイレクト設定追加』という作業の手順書を作ってみたいと思います。

▼手順書

コマンド3個の簡単な手順書が出来上がりました。それでは、早速作業に・・・と進みたいところですが、まだ大事な確認ポイントが終わっていません。それは、手順書レビューです。

確認ポイント2：レビューしてもらいましたか？

レビューとは手順書作成者とは別のエンジニアに手順書を確認してもらい、手順の誤りなどが無いか確認してもらう作業です。新人エンジニアの場合、普段から教えてもらっている先輩エンジニアに頼むと良いでしょう。

では、この作業手順書をレビューしてもらった結果、どんな結果が帰ってきたでしょうか？

▼レビュー結果

• 何の手順書かわからないので、適切なタイトルを付けて下さい。
• 作業するサーバーと実行ユーザーを明記して下さい。
• プロンプト（コマンド前の記号）が $ ですが、一般ユーザーでの作業でしょうか？ root ユーザーで実行するか sudo を使用しなければ、実行できないように見受けられます。
• httpd.conf 変更追加前にコピーを取得して下さい。何か問題があった時の切り戻しに使いますので。
• 念の為、設定追加前後の diff を取って、余計な文字が入ったりしていないか確認して下さい。
• graceful 前後で Apache のプロセスと LISTEN ポートの状態に変化が無いことを確認して下さい。
• 動作確認が不十分だと思います。以下のテストパターンも追加して下さい。
  • http://www.techscore.com/aaa/bbb → http://www.techscore.com/blog/bbb リダイレクトされる
  • http://www.techscore.com/aaaa/ → リダイレクトされない

たくさん指摘されてしまいましたね・・・上記の指摘を受けて修正したものが以下となります。

▼修正した手順書

最初と比べるとずいぶん長い手順書になりましたね。しかし、長くなった分ミスなく作業を実施できるようなしっかりとした手順書が出来上がりました。

確認ポイント3：作業は2人で確実に

それでは作業の実施です。ここでも、ポイントがあります。”2人で”という部分です。2人で作業するということについてあまり想像できないかもしれませんが、実際にコマンドを打つ『作業者』とその様子を見守りチェックする『確認者』にわかれて作業をします。

確認者の役目は何かというと、作業の重要なチェックポイントを一緒に確認したり作業者がミスをした際に、すぐさまフォローしてあげたりする役目があります。

意外とちゃんと手順書を準備していても、手順書から SSH端末にコピペするときに、コピペミスでコマンドがエラーになったりしてしまうものです。そういう時、作業者は動揺しがちなのでしっかりと確認者がフォローしてあげることが極めて重要です。

また、作業者・確認者とも声を出し、画面を指さし確認しながらきっちりと作業を進めていくことも重要です。上記手順書から Apache の 設定ファイルの構文チェックをするときを抜き出したら以下のようになります。

作業者：「Apache の configtest します」
確認者：「はい」
作業者：コマンド実行
作業者：「Syntax OK」（画面を指差し）
確認者：「Syntax OKです。」（画面を指差し）「次に進んで下さい」

Syntax OK（構文チェックに問題が無かった）ことを作業者・確認者とも確認し、次の作業に移っていますね。こうやって声を出して1個ずつ進んでいくことで、作業の抜け漏れを防ぐことが出来ます。

最後に

長々と書かせて頂きましたが、結局この記事の結論はというと『1人作業ではなく複数人で作業することが大切』ということかと思います。新人エンジニアの皆さんにとっては、なんでこんなことまでいちいち手順書作って承認貰ってお役所仕事な・・・なんて思う方もいらっしゃるかと思います。

しかし、こんなものは優しい方で、先輩エンジニアにお聞きした話では、以下のようにお役所仕事を通り越したような厳しい現場もあるそうです。

• 本番環境では、手順書に書いていないことは一切やってはダメ。たとえ ls を打つだけでも。
• 本番環境での作業は全てログにとり、お客様に提出。（手順書に書いていない作業をしていないかすべてチェック）
• 手順書から本番環境にコマンドをコピペする際に、手順書をコピーした際のメモリのバッファが正しいか、試しペーストしてから、本番にペーストしなければならない

それを考えれば、この記事に書いたことは序の口といったレベルでしょう。

新人エンジニアにとって、先輩の手順書をレビューしたり、先輩の作業に立ち会ったりすることは貴重な経験になると思います。

Linux 本番環境で作業されることがあれば、この記事のことを少しでも思い出して頂ければ幸いです。きっとミスしない作業につながりますから！！

謝辞

手順書の書き方につきまして、湖山翔平さんが発表されました『インフラエンジニアの綺麗で優しい手順書の書き方』を参考に、社内のテンプレートを作成し使用しております。この場をお借りしてお礼申し上げます。