AWSエンジニア、Chef/Puppet自動化大好きは地雷？現場で重宝されるスキルの選び方

今や時価総額世界第2位(2018.06時点)の Amazon。そのインフラを支える Amazon Web Service (AWS) を職務経歴書に真っ先に書いてしまうエンジニアがいるが、いまどき VM を立てるだけのエンジニアに高いお金を出す企業はない。Chef や Puppet (いやせめて Ansible だろうが)で自動化を成し遂げたと胸を張るエンジニアも危険である。
[adinserter block="1"]
CentOS や Oracle などの定番ミドルウェアを扱った経験があると声高に叫び、職務経歴に「10年のキャリアがある」と書くエンジニア達。だが、フリーランスエンジニアの価格は7,8割、お仕事をする「前」に決まる。彼らの職務経歴を見ただけで、「地雷だから回避しよう」という力が働き、年俸500万そこそこが提示され、結果彼らは負ける。

そのレベルで燻っているエンジニアは、持っているスキルが弱い。ではどうすれば魅力的なスキルが手に入るのか。それが今回の趣旨だ。

あなたの肩書き、メインスキルはなんですか？

前回のエントリでも書いた通り、「○○株式会社　プロジェクトマネージャー」や「フリーランスエンジニア」は肩書きです。肩書きだけで業務委託が決まったり、あるいは転職先が見つかれば万々歳ですが、そのようなケースはほとんどなく、エンジニアはすべからく今まで培ってきたスキルを職務経歴という形で記載し、企業はそれをジャッジします。

数年前まで、インフラエンジニアは AWS や Chef/Puppet、VMWare あたりを職歴に書いておけばそこそこ評価された時代でした。しかし、インフラエンジニアが「インフラ」だけに目を向け、自身がメンテするマシンのことだけを考ればよかった時代は終わりました。今や DevOps の概念は当たり前であり、生産能力を発揮する開発チームに寄り添えないインフラエンジニアは目の上のたんこぶでしかありません。また経営陣からしてもマネージドサービスがあればいいという考え方もあるでしょう。

今や生き残るインフラエンジニアと切り捨てるべきインフラエンジニアは白黒はっきりする時代。これからのメインスキルを考えましょう。

[adinserter block="1"]

レンジがインフラ「だけ」なのは低評価

例えば、あるプロジェクトでの機器構成や担当をこんな風に書いている人、いますよね？

機器構成

• サーバ約100台(UNIX, RAID5)
  • AWS EC2 にて構築
  • OS: CentOS, RHEL, Solaris
  • DB: Oracle, MariaDB
  • Zabbix, Hinemos による監視

担当

• サーバ(Apache)構築、運用、保守、パフォーマンスチューニング
• サーバ(MariaDB)構築、運用、保守、パフォーマンスチューニング
  • Master/Slave 冗長化構成の設計
• シェル・Perlでの監視・保守ツール作成

もしも企業側の人事が非テクニカル職の人だけで構成されるような場合は厳しいジャッジを免れることができるかもしれませんが、フリーランスエンジニアに仕事を振ろうという会社は間違いなくテクニカル職の方が選考に関わっています。

彼らからすると、上記のような内容の職務経歴は、どれだけ経験年数が長くとも「地雷」と見なされます。なぜでしょうか。

ストレージ冗長化、DB冗長化、そして監視周りを含んでおり、一見して一通りの経験があるように見えます。ところがこれが地雷人材と見なされる理由は2つ。1つめに 仮想化のパラダイムシフトに追いついていないこと、2つめに SDx、及び DevOps 重視の業界事情に追いついていないことを 自ら暴露している 経歴書だからです。

「インフラは常に社内で健全運用しなければいけない大事な部分なんだ、そう簡単にイマドキのものなんて取り入れられないよ」

こんなことを言うインフラエンジニアの声も聞こえてきそうですが、それこそ期待外れ。現場も経営陣も、「安定だけ」「インフラだけ」のエンジニアなど欲していないのです。

では現場と経営陣に寄り添ったインフラエンジニアであれば何を行ったでしょうか。

魔法の篩(ふるい)、コンテナ仮想化技術とCI/CDツール

まずは「現場に寄り添う」とはどういうことかを見ていきましょう。

2015年あたりまでは、VMレベル、つまり EC2 や KVM レベルでサーバー機を用意し、その上に必要なミドルウェアを載せていくのが当たり前でした。しかしそこから、docker を中心としたコンテナ仮想化へのパラダイムシフトが急激に進みます。上記経歴ではそこをまったくカバーしていません。

そしてより重要なのは DevOps 関連の技術の列挙、特に CI/CD ツールの構築だけでなく、メンテにどれだけコミットしてきたかです。

アプリケーションエンジニアにとってはお馴染みの CI/CD ツール。Continuous Integration, Continuous Deployment の略です。実際のオンプレミスに載せるツールとしては Jenkins が有名処、クラウドでは Travis や Circle CI が有名です。

コンテナ仮想化により、各種ミドルウェアの準備は格段に楽になりました。docker-compose コマンドを一回叩けば、Let's Encrypt と nginx による SSL Proxy を備えた何かしらのアプリケーションがものの数分で立つようになったのです。本番環境にもコンテナ仮想化を使うアーキテクチャが当たり前になってきたのは2017年頃からですので、その経験がないというのはまだ許されるにせよ、開発環境では当然コンテナ利用が進んで久しいわけで、ミドルウェア構築が楽になった分、現場ではインフラのレンジを超えた貢献が求められていたはずです。そこの経験が全く無いのは、業界でアンテナを張ることをせず、安穏とインフラだけを見つめ続けてきたことの証左です。

現場に寄り添ったインフラエンジニアであれば、以下のような経験が追加されていたことでしょう。

担当

• docker を利用した各種サーバのリプレース
• Jenkins の構築、運用、保守

たったこれだけですが、「箱は準備して監視は設定しといた、あと好きに使って良いよ」という日和見インフラエンジニアを篩にかけるには十分です。

[adinserter block="1"]

残念すぎる「自作ツール」群

さらに一発アウトなのがこちら、「シェル・Perlでの監視・保守ツール作成」。

サーバ構築は台数が多ければ多いほど手作業が増えますので、Ansible, Chef, Puppet を用いた構成管理ツールの記載なしに「保守ツール作成」と書いてある場合はかなりの地雷確率アップです。インフラの規模が小さかった等で自動化の経験が全くない場合は設計経験をより詳細に書くのがベター、ツールの作成等は書くべきではありません。

 

安心するのはまだ早い、「AWS エンジニア」「構成管理スペシャリスト」が地雷になる日

冒頭でも書きましたが、AWS 自体の人気と価値は計り知れないものです。しかしそれは AWS が EC2 や S3 といった比較的レガシーなサービスのみで成長を続けているわけではなく、たとえば RDS のような過去の資産を活かせるマネージドサービス、Lambda や Kinesis といったマイクロサービスやサーバーレスアーキテクチャの構築を支援するプロダクト群、その他数え切れない価値ある AWS ファミリーの提供を行っているからです。

そんな中、社内のオンプレミス環境を EC2 に置き換えるのみで「クラウド化」と呼んでしまうインフラエンジニアは早期に地雷化します(あるいはもうなっているかもしれません)。というのは、会社の状況に応じたインフラ選択を進言してこそ、「経営陣に寄り添う」インフラエンジニアとして重宝されるからです。

EC2 は VM の管理を AWS に任せることで、確かにオンプレミス環境にあったストレスをいくらか低減してくれます。しかし VM の中身、OS とアプリケーションの間の領域は依然として自社のエンジニアが見なければならず、結果的にそこにもコストがかかっているのです。

「経営陣に寄り添う」エッセンスがまさにこの部分、コストダウン意識にあります。つまりテクニカルなことに気を配らない経営陣がいたとしても、コストダウンに気を配らない経営陣はいないので、必要に応じて更にハイレイヤーのマネージドサービスを検討した方がトータルでのコストパフォーマンスが上がる可能性があります。

そんな中、Kubrnetes が Docker に統合され、名実共にコンテナ仮想化オーケストレーターとなりました。2018 年は k8s 普及元年となりそうです。アプリケーションインフラに対しても、これまでの常識を一旦リセットし、ディプロイメント設計コスト、スケーラブル環境設計コスト、フェイルオーバー設計コストを自社エンジニアが引き続き払うのか、ある程度学習コストを覚悟した上で k8s クラスタに任せるのか、そういった提案を誰かが行う必要があります。構成管理ツールと比べても、k8s は Infrastructure as Code を可能にしたまま、エンジニア(人)が管理しなければいけない領域と概念を大幅に書き換えています。

[adinserter block="1"]

まとめ

今回は「インフラエンジニア」の領域での「地雷」評価がいかなるものか、そのような評価を回避するスキル・経験の身に付け方についてお話ししてきました。是非、ご自身が今まで考えてきた守備範囲と、これから現場・経営レベルで必要とされるインフラエンジニアの守備範囲がなにか、見直してみてください。

 

 

 

ハリー

Profile：エンジニア歴15年。現在もバリバリのエンジニアとして一線で活動中。