エンジニアならわかる、システム運用のあるある体験！「インフラエンジニア川柳」に共感が止まらない

担当している業務は人によって本当に様々だと思います。ITインフラには、ストレージ、サーバー、ネットワークなどのハードウェア、さらにはデータベースや開発フレームワークなどのミドルウェアまで、幅広い領域が存在するからです。その中で私は、お客さまのネットワーク自動化の支援を主に担当しています。

大規模な社会インフラに携わっているエンジニアも多く、「なりすまし」などの不正アクセス対策業務もあります。いわば、水面化の見えないところで、皆さんの安全を守っているわけです。「頼むから 『何も起きず』を評価して」という川柳は、その仕事の醍醐味を上手く描いていると思いますね。

システムの運用作業においても、何も起こらないようにメールサーバーの容量を確認したり、データベースで何かバグが起きていないかチェックしたり、注意深く見ています。

例えば、ソーシャルゲームにおける「サーバーダウン」は完全にアウトで、その手前でアラートを鳴らしながらくい止めていることはよくあります。 皆さんの見えないところで、陰ながらがんばっているということですね。

川柳でも「テスト機と 構成違う 本番機」という作品が入選していますが、テスト時と本番の環境が違って苦労することもあります。できれば同じであってほしいところですが、事前に想定できないことも多いです。

例えば、本番になった途端に厳しくファイアウォールで防がれてネットワークに接続できないパターンもありますね。インターネットにつながるかどうかで、作業の難易度は変わってくると思います。

事前の対策としては、まず本番環境とテスト環境の差分っていうのをちゃんと確かめて、どこでエラーが出ているのかを切り分けていく。レイヤー層で下から上に行くっていうのが基本で、ちゃんと有線がつながっているのかどうか、ネットワークの設定は正しいのか、そして最終的なアプリケーションの設定が正しいのかどうかなど、細かくチェックしていくことが大切です。

「デートより アップデートに ドキドキし」、この川柳は本当に上手いですね。エンジニアの心理を巧みに描いていて、個人的には座布団10枚をあげたいところです（笑）。

というのも、アップデートの前には、例えるなら東京タワーの電波をスカイツリーに移すくらい大掛かりな対応が必要になることもあるからです。

この場合は、従来のアナログコンテンツを全てデジタルに直すことも行わなければならないわけですが、ITインフラのアップデートでもそのくらい大がかりなことをする場合もあるんです。普通のデートなら、楽しみで眠れないかもしれませんが、アップデートの場合は不安で眠れないこともあるのではないでしょうか。

まず「検証環境」でアプリケーションの動作を確認するところから始めます。本番と全く同じ、デモ画面のようなところで何も起きないことを確認していくんですね。全パターンで何も起こっていないことを確かめてリリースに踏み切るのですが、テストをどんなにやってもリリースをしたときに上手く動作しないことがあります。原因は、アプリケーションのバージョンに関わることなど様々です。

そんな背景もあり、最後までドキドキが止まらず、1週間ほど安定的に動いてくれたときに、ようやく安心できますね。

私が特に共感したのは、「半角の スペース一つ 大惨事」という川柳です。半角スペースを一つ入れただけで動かなくなるツールも多いので、この苦労はよくわかりますね。

例えば、Python製のインフラ構築自動化ツールは、スペースの検知が非常に厳格です。スペースを2個空けないといけないところを、3個空けるとエラーが起こる形式になっています。古いエディターを使っている場合は自動検知できないため、目視で見つけづらいことが多く時間がかかります。

プログラムだけではなく、ネットワークでも同じようなことが起こります。通信を行う際に各機器に対してパスワードを設定することがあります。このパスワードはどちらも同じパスワードにする必要があり、異なるパスワードの場合上手く接続出来ない場合があります。パスワード設定の際に不要なスペースが入ってしまうとまずいことになりますね。

例えば、「ABC」っていう3文字のパスワードがあったとして、「ABC 」という風にスペースが入ってしまうと、最後のスペースも1文字となり、4文字のパスワードとして認識されます。見た目では同じなのに、プロトコル上で不一致になり、「あれ、繋がらない」という状況に陥ってしまうわけです。

プログラムに関しては、プログラムのエディターをしっかり使うこなすことが第一の対策だと思います。また、書式を確認してくれるチェックツールもあるので、適宜活用するのがオススメです。

ネットワークに関しては、それぞれの機器データを取得して、コンフィグレーション同士をテキスト比較ツールで確認する方法がいいかもしれません。

「半角スペース」でシステムが止まることもあれば、逆にエラーが起きているのに挙動としては上手くいっていることもあります。

その状況を描いているのが、「動いてる なんかしらんが 動いてる」という川柳ですね。アラートが出ているものの上手く通信できるとか。エンジニアとしては、むずがゆいところですね（苦笑）。

私が経験したケースでいうと、ある時にアプリケーションをインストールするシステムの構築に取り組んでいましたが、何度やってもその日はエラーが出ていて動きませんでした。色々と確かめながら取り組んでいたものの、全く上手くいかずその日は諦めたのです。しかし、翌日になって動かしてみると、前日が嘘のようにスムーズに動作確認が完了しました。

原因をはっきり特定することは難しいですが、システムの新たな設定が反映される前に動かしてしまったことが考えられます。その他にも、システム内の不整合で上手くいかなかったのではないかなど、色々と原因は考えられます。それも含めて、何ともむずがゆいところです。

これは現場でよくあることなのですが、「皆様のリモートのためにフル出社」という川柳ですね。サーバーというのは、一箇所だけに設置されているわけではなく、緊急時のことも想定して関東・関西など、いくつかの場所に分けて置かれています。そのため、サーバーの増設や電源設備の調整などが必要なときには、旅行のようなかたちで出張することもあります。

また、企業によってはエンジニアの出社が義務付けられている場合もあるので、他の方のために陰ながらフル出社でがんばっているインフラエンジニアは多いと思います。

「リモートで クリックしたのは シャットダウン」という川柳が入選されていますが、これは私もリモートデスクトップで間違えてやってしまった経験があります（苦笑）。リモートデスクトップを使っている場合は、会社に置いてあるリモートPCはシャットダウンせずに、自宅のPCの電源を切れば良いのですが、間違えてリモートPCをシャットダウンしてしまうと、会社に行かないとPCを起動できなくなります。

会社に誰か人がいるのであれば、連絡して「すみません、リモートPCの電源を入れてください」と頼めますが、もしいなかったら自分で出社する必要があります。さらに、サーバーを誤ってシャットダウンしてしまうと、遠方に出張しないといけないケースもあるので非常に惨めです（苦笑）。

普通はシャットダウンの直前で「これは違う」と気付くのですが、例えば両方ともWindowsだったりすると分かりづらいことも多いと思います。万が一の事態を防ぐためにも、終業時に自分のローカルであることを一目でわかるように、デスクトップには何も置かない、壁紙を変えておくなどの対策をしておくことが大切です。エンジニアによっては、リスク回避のためにPCの電源をあえて切らない方もいらっしゃいますね。

私が思わず共感したのは「一言も 誰ともしゃべらず 日が暮れる」という川柳ですね。一時期、誰とも話さずに一日が終わってしまったことを思い出しました（笑）。

お客さまと作業しているときや、チームで活動するときには話したりすることは多いんですけど、案件の切れ目のときなどは社内の作業に黙々と取り組む日があります。「いつの間にか一日が終わっちゃった」という感じですね。とはいえ、会議ばかりで作業が進まないのもエンジニアとしてはつらいので、バランスが大事だと思います。

「そうですね 技術的には可能です」というのは、私たちエンジニアがよく言うフレーズだと思います。文面通り技術的には可能なのですが、その後に「だけど」が付くんですよね。「じゃあやってください」みたいな感じでお客さまとのやり取りが始まることが多いのですが、エンジニアの想いとしては「技術的には可能だけど…」という複雑な心境のこともあります。

まず、開発費用がかなり必要になるパターンがあると思います。あとは、構成が複雑になってしまったり、推奨の構成じゃなかったりすることも。理論上はできるのですが、実際にそれを実行するとなると色々と考える必要があるということですね。

これらのやり取りの背景には、お客さまがシステムや技術についてどれだけ知識を持っているのかが大きく影響してきます。色々なことを知っている場合は、「こういう技術を使えばいけるんじゃない」というように先方から提案されることもありますね。

一方で、インフラについて詳しくないお客さまから「こうしたいです。できますか？」と相談されるケースもあります。その場合は、「これもしたい」「あれもしたい」と希望が広がりすぎるのを防ぐために、「まずは第一優先でこれをやります」という風に内容を整理しながら提案するようにしています。

私が特に共感するのは、「みんないう なにもしてない こわれたと」という川柳です。皆さんよくおっしゃるんですよ、「え、何もしてないですよ」「全く身に覚えはないんです」と。

しかし、先ほど海老澤さんが話していた「半角の スペース一つ 大惨事」の川柳が示しているように、半角スペース1個違うだけで、全く違う挙動をしたりするんですね。エラーの原因を特定するのがとても大変なので、心当たりのある方からは、出来るだけ詳細な情報を引き出すことが重要になってきます。まるで刑事ドラマの捜査みたいですね（笑）

エラーを解決するために運用作業の基本となるのが、「ログを見ろ ドキュメント見ろ コピペしろ」です。重要な言葉なので、川柳でも入選されていますね。

何か問題が発生したときには、まず「ログを見る」。ログにエラーが出ているのかを確認して、エラー番号が出ていたら、その番号の「ドキュメントを見る」。例えば、エラー番号が5○○だったら、その番号のドキュメントを見て、その対策コマンドを「コピペして」実行に移せば対策完了です。

しかし、残念ながら毎回このようにいくとは限らないんですね。ドキュメントに書いてある通りのことが起きれば、誰でも作業できるんですけど、予想外のことが起きることもあります。そんなときでも焦らず、自分で抱え込まずにまず「報告する」。これは非常に大事だと思います。時間との勝負なので、まず報告して、よく知っている人たちに考えてもらい、すぐに対策を打つようにしましょう。報告と対処が完了したところで、その手順をドキュメントにまとめれば、「ログを見ろ ドキュメント見ろ コピペしろ」を他の人も実践できるようになります。

一番嬉しいのは、お客さまが新たにシステムを導入して「便利になったよ、ありがとう」と感謝の言葉をいただくときです。案件的に長いものだと数年単位になることもあるので、「ありがとう」と言われるだけで「がんばって良かった」と今までのがんばりが報われたような気持ちになりますね。あとは、ネットワークに繋がらない状態から、技術検証で上手く疎通したときには大きな達成感があります。