転職して幾月か経ち、ふと引き継ぎ業務について考えた。

なので僕自身が引き継ぎ業務においてどう考えているか、どうあるべきか、また前職においてどう引き継ぎをしてきたかということを述べたい。

長いです。

引き継ぎ業務とはなにか

  • 現状の業務内容を自身が不在となった後も継続して行えるよう取り計らうこと

と至極当たり前に考える。これを第一義とする。

引き継げないこともある

  • たとえば想定し得ない障害時の問題解決とその手段
    • これは属人的であり個々の能力に依存するため、原則的に引き継げない
    • この「引き継げない能力がある」ということを「退職者リスク」と呼ぶのではないか

「引き継げないこともある」まで考えてたうえで、それでも言語化して引き継ぐことを諦めない

  • 「想定し得ない障害」があるのであれば、「引き継ぎ時に想定できる障害」もある
  • それならば更に一歩踏み込んで「仮想的な障害ケース」を言語化できないか考える

などを最終的な心構えとする。

誰に引き継ぐのか

  • 第一義である「現状の業務内容を自身が不在となった後も継続して行える」ようにすべき引き継ぎ相手は誰なのか
    • 自身と同程度以上のスキルを持った相手ならば引き継ぎコストは最小となる
    • しかしほとんどの場合においてそうではないと思える
    • 自身が当該部署のエースのような存在であった場合には、引き継ぎコストは大きい
  • また「引き継ぎ相手のスキル」を規定するのは自身ではなく企業文化に大きく依存する点を忘れてはならない
    • 技術者にどこまで採用コストをかけられるか
    • 企業にどれだけの給与を支払える体力や文化があるか
    • など企業の人事的意思決定に依存する
    • 究極的な話になると以下を考えようということ
      • LLなScriptを理解できるのか
      • Shell Scriptが読めるのか
      • Cisco系Switchを触れるのか
      • そこらへんのPCにLinuxをインストールできるのか
      • 一回でもSSHしたことがあるのか
      • そもそも日本語が読めるのか

未知なる彼/彼女は悲しまないか

これは自意識過剰とも思える事柄である点留意されたし。 前職に転職した当時の恨み節をポジティブに変換した結果である。

  • その引き継ぎで果たして今目の前にいる引き継ぎ担当者にババを引かせることがないか考える
  • また、それ以降に採用された(中途であれ)新入社員にもババを引かせることがないか考える
    • これは自身が、当時ドキュメントの不足(というか全く無かった)により文脈を捉えきれられずに起きたいくつかの障害を経験したことによる

ここまで考えたうえで自身の引き継ぎを語る

僕自身はオンプレミスなITインフラ担当エンジニアであった。後期にはAWSを触るなどしたが企業にとって重要なシステムというわけではなかったので、語るのはオンプレミスな環境である。 さて、引き継ぎにおいては以下の点が引き継ぎ担当者を悩ませるものであると理解している。

  1. 採用されている技術知識
  2. 採用されているOS/ミドルウェアのソフトウェア知識
  3. 実装の意味、またはビジネスに関連した経緯/文脈

これらは数字が大きくなるほど引き継ぎ担当者は悩み、ストレスとなる。特に 3. はググってもでてこない情報だからとも言える。知っている人は知っていて、知らない人は知らない(というより知り得ない)内容だったりする。僕自身 3. も含めて非常に悩み苦しんだ。そして恨みと怒りが頭をもたげその反動でこの苦しみを断ち切る覚悟をした。

事例1 Zabbixについて引き継ぐ

前職では、比較的理解があったので監視業務にZabbixを導入した。この時点で引き継ぐ必要が生じたことは理解していた。先述した内容にあわせて引き継ぐべきだと考えたポイントを書く。基本的に「未知なる彼/彼女は悲しまないか」を念頭においているため、非常に冗長であった点ご容赦願いたい。これらを冗長だと感じる人が引き継ぎ担当者であればそれは企業においては幸せなことなのだから許してほしい。

  • LAMPをざっくりでもいいから理解してもらう
    • WordPressを構築してもらうことにした
    • WordPressやZabbixはLAMP初学者(特にLinux)において良い教材だと考えている
  • Zabbix設定ファイルの差分を明確にする
    • 環境ごとに変更すべき点
    • 特定監視設定を盛り込みたいHostに設定すべき点
  • ダッシュボードの"インストール"を隠す
    • 再インストール可能性を極力減らす

どう運用するか引き継ぐ

Zabbixのような監視システムがあると、Zabbix自体に恐怖心を抱く人もいる。 「システム障害はいやだ」→「障害を検知するZabbixは重要だ」→「Zabbixは神聖にして不可侵な存在だ」というような連想が働くのかもしれない。とにかくZabbixを理解して引き継いでもらわなくては、この監視システムは塩漬けになる可能性があり、塩漬けになった時点で負債になる。企業にとっても引き継ぎ担当者の将来にとってもよくない。

  • 監視アイテム設定方法について理解してもらう
    1. サービスには主に以下があること
      • プロセス
      • ポート
    2. 上記を踏まえて「では障害とは何か」を理解してもらう
      • プロセスが死んだらもちろんダメ
      • プロセスが生きていてもポートが閉じていたらダメ
        • ここは文脈に依存する部分で、前職においてはFirewall機器はなくiptablesやTCPWrapperで運用していたため、設定ミスからのポート遮断/ACLによるアクセス不可は考えられるので
      • もっと言えば以下も理解してもらう
        • 期待通りのレスポンス時間でなければダメ
        • レスポンス内容が不正であればダメ
    3. 2.を経たのならばトリガーの説明がしやすい
        1. を言語化してもらいどういう設定が必要か、またこう考えたからこの設定にしたんだということを理解してもらう
    4. 設定内容が文脈に依存する場合、そのような設定名にしてあることを伝える * 引き続きそのように運用してほしい希望がある旨を伝える * 設定項目の説明やURLに経緯や想定内容、議論のあったチケット番号、Wikiへのリンクなどを記載し希望を託す
  • UserParameter について理解してもらう
    • Zabbixにおいて万能感を得られる機能なのでぜひ理解してもらう
    • またこの存在の理解がないと、Zabbixのドキュメントをあたっても当然そのような独自のキーはないので不明なアイテムについての答えが得られず、Zabbixを嫌いになってしまう可能性がある
  • 不適当な監視設定がない状態にしておく
    • 引き継ぎ担当者は現状を正とみなす傾向がある
    • そのため「間違った設定が正しく動いているように見える」ことは「全く動かない」ことよりも質が悪いと考える

などを念頭において引き継ぐようした。

事例2 サーバ構築について引き継ぐ

自身において誇りに思う部分でもあり、不十分だったのではと後悔する部分でもある。誇りに思う点は恨みと怒りを糧に自身が携わったすべてのサーバ構築をShell Scriptで再構築可能にした点である。また構築時には移設を前提に考えうる限りの構築をしたため、結果単体の障害はあったもののサービス停止するような致命的障害は一切なかったことだ(寝ずに障害対応する羽目になったのは僕が構築した以外のサーバだったんだ、ほんとだ!!)。

後悔する点は当時すでに叫ばれていた、サーバ構築自動化を達成できなかった点だ。ただこれには以下の言い訳がある。

  • 構築自動化が効くのは、オートスケールなどが必要な場合ではないか
    • 常時のサービス提供時に負荷が高く問題が起きることはなかったので、同一環境で同一ロールのサーバがさらにもう一台必要となることがなかった
  • そもそも構築自動化を実現する Chef や Ansible を導入したとして、それらの運用(サーバ設定変更すべてをそれで賄うという鉄の掟)を果たせる引き継ぎ担当者を期待できるのか
    • Shell Scriptならまだ理解してもらうことは期待できるのでは

というところだ。

どう構築したか引き継ぐ

いままで自身が見てきた「手順書」というやつは、すべてがすべてなぜかMSのオフィス製品ドキュメントで書かれていた。誰が嬉しいのかわからないので僕はShell Scriptで書いた。また引き継ぎ担当者が迷う部分は「サーバ設定に関して差分は適宜考慮してね」というパターンであることは過去の経験から認識していた。なので「サーバ一台に対して一組のShell Script群」というルールを課し、愚直に対応サーバ一台一台ごとに冗長ながら構築手順スクリプトを残すことに決めた。「同一RoleのサーバAとBにはAとBそれぞれの構築手順スクリプトがある」という具合である。またベースとなるいわゆるゴールデンイメージ相当のKVMゲストイメージはあったものの、そこからの手順と、(CentOSだったので)minimalパッケージからの構築との2種を残した。

なぜそこまでしたのか

これは「Linuxにおける個々の設定方法を理解してもらえるのではないか」という期待である。もちろん無理解でもScriptを流せば構築は可能にしてある。だがもしも応用すべき構築案件が出た場合に「このスクリプトのどの行が以下の機能の設定にどう結びついているか」理解してもらえるのでは、という淡い期待があった。

  • IPTables
  • TCPWrapper
  • Apache httpd(Yum,Source)
  • MySQL/MariaDB
  • Postfix
  • Yum
  • Zabbix-{Server,Client}(前述したとおり)
  • Munin
  • ntpd
  • tomcat
  • PHP(Yum,Source)
  • OpenSSL(Source)
  • OpenSSH(Yum,Source)
  • logrotate
  • /etc/sysctl.conf
  • /etc/hosts
  • /etc/resolv.conf

別途理解してもらいたく何度も繰り返し伝えたこと

「通信ができない」というときの問題解決法

これはある程度経験を持ったITエンジニアでも度々はまる内容である。「あるAPIが叩けない、なんで」というパターンだったり、「メール送れない、なんで」というパターンだったりする。どちらかというと本番環境よりも、本番環境と差異のある開発環境で起こる軽微なトラブルである。ただこれで数時間無駄にしたりすることがあるのでよくない。以下に自身が問題解決にあたった際のアプローチ方法を書く。

  • まず名前解決を疑う
    • dig や nslookup してるけど結局 /etc/hosts だった
    • 疎通確認でなく名前解決確認として ping ${FQDN} が役に立つことを知ってもらう
      • 前提として自身が構築したサーバ群では /etc/nsswitch.conf はいじっていない
      • 欲を言えばMTAを一度構築してもらうとこの辺り非常に素早く対応できるようになる印象
  • 問題を最小の粒度にして限定的かつ明示的に言語化する
    • ○○ができない ではなく Aからhttp://B/v2/hogeが叩けない など
    • From A と To B:port のセットで語るようにする
  • tcpdump と WireShark を覚えよう
    • 自身が現場で出会った「インフラ」エンジニアは総じてプログラムを読めない
    • 自身もそれほど読めるわけではなかった
    • それでも問題を解決しなければならないとき、tcpdump は最高のツールだ

というくらいか。

以下は当該企業の諸事情による問題解決法

Apache httpd(実際にはさらに間に mod_jk などがいた) と Tomcat という構成だったことが関係するが、このあたりが非常にサービス運用を複雑でわかりづらくしていた。というのも httpd.conf で mod_rewrite が多用されているからだ。mod_rewrite の行先は Tomcat のAPIなのだが、つまりはAPIが機能するためには Tomcat 単体で完結せずに httpd.conf に一部実装が依存し分離されていることを意味する。なので httpd.conf を誰も触りたがらなくなった。 1

どうしたか。httpd.conf の mod_rewrite 部にコメントで叩かれる API についての端的なコメントと、その解説を書いたWikiのURLを書いた。また「このRewiteが正常に機能しないと、特定の認証が通らない」など起こりえる事象も添えた。また「mod_rewrite から Tomcat との連携を自身ではソースを追うことなく行えることもある」という点から tcpdump を理解してほしいと伝えた。さらに言えば「開発陣」と「インフラ運用陣」の垣根みたいなものも感じたのでそれを取り払うよう努力した。2

最後に

正直盛りだくさんだと感じる。引き継ぎ期間だけでははっきりいって足らない。ではどうしたか。僕自身はいつ辞めてもいいようにしてきた。つまり入社してから主要な作業に関してすべて簡易ではあるがドキュメントを先んじて用意した。構築時もそう。ドキュメント(という名のShell Script)を先に検証時に作成して、本番はそのScriptを実行するだけにした。もっと言えばそのあとにそのサーバを破棄して、再現性まで確認した。それが正しいと思ったからそうしてきたし、その再現性の追求は別環境の構築などの作業効率を高めた。3年間で構築した台数は50〜60程度ではあるが、関わった環境は5つに及ぶ。それぞれ独自の文脈を持っている環境なのだが、再現性を高めることを最初に徹底した結果、それぞれで「独自の文脈を解決しドキュメントに残すこと」だけに集中できた。

また自問する。なんでそこまでやったのか。当時は単純に怒りからくるものだった。この苦々しい無責任さからくる憤りを誰かに同じようにさせてはならないと感じた。だからやった。でも今振り返ると違うことが言える。

一つにやはり企業の台所事情というのがあると思う。レガシーなシステム相手にしても、前に進まなければならない時がある。多くの企業がそれを当然と考え機能追加を試みる。ただ実際には言うほど前に進まない。なぜかといえば毎回「この機能に依存するライブラリ/インターフェースってなんだろ」とか「この処理が呼び出す先ってなんだっけ」というような文脈が追えずに後戻りするからだ。文脈を追うのを怠れば、システム障害やバグを埋め込む苦い経験をしているから、だから新機能の実装をするために古いコードなりドキュメントを読む羽目になる。「読む」だけならいい。そのドキュメントを探すところから始まることだってあるんだ。「あれ？ 俺はシステムに機能追加がしたいんだよね？ なんでファイルサーバで find 実行してるんだ？」

引き継ぎが満足にいかなかったほとんどのITエンジニアは、現場で前に進む際に後戻りすることを余儀なくされているのだと感じる。この前提を真とすると「障害を未然に防ぐ保守運用の立ち回りの正解は『何もしない』こと」になる。開発との信頼関係がないからだ。でもそれはあまりにもよくない。やらないことを正当化するためだけに給料を貰ってる人がいるなんて信じられない。

だから僕は「後ろにだけは一歩も戻らない」ことを考えて、(少なくとも)最小の手戻りで解決するよう努力したんだと思う。3

もう一つ。多分こちらのほうが強い。僕は素人同然で偽装派遣な保守運用エンジニアとして正社員となって経緯がある。少なくない情報をWebと書籍から得た。なので同じようにキャリアを始める人、またキャリアを始めたけど経験が浅い人、つまりは「未知なる彼/彼女」にとっていい手本でありたいと考えているのがある。僕のドキュメントが冗長なのはそこらへんが由来している気がする。「これ読んだらわかるよ」と言うのはかっこいいことだと信じた結果なのだと思う。

  1. 実は「開発環境と本番環境でmod_rewriteの内容が違う」というそもそも論もあった ↩︎

  2. 自身の担当領域が機能するために、他の領域のどの機能に依存するか把握し啓蒙しないのは不誠実と感じた部分が大いにある ↩︎

  3. スタートアップとか、成長期とかだと当然違う選択肢もあるのだと推察する。 ↩︎