インフラエンジニアのぼやき

 2018.09.20  株式会社テリロジー 技術統括部

急に技術の記事を書けと言われても書けないですよ。ということで、日記を書きますが、どこぞの特定のサービスについての不満を書いているわけではないです。

最近はクラウドファーストどころか、クラウドマストの傾向があります。ひと昔前はクラウドはセキュリティが心配だから、なんて人もいましたが、いまでは、クラウドならセキュリティ面は安全だ、なんて言う人もいるわけ。不思議です。

そういや、つい最近、「クラウド」という製品があると思い込んでいるUMA級の御仁(オジン 死語)に奇跡的に出会いましたが、ええい、この際、そいつは宇宙の彼方に投げっぱなしジャーマンしておくことにします。

今更ですが、クラウド化により、インフラエンジニアが不要になるという人がいます。自分はクラウドがわからないから、インフラエンジニアとしての役目は終えたとか言っちゃう人もいます(じゃあ、勉強しようぜ)。別にクラウドにしたからと言って、インフラエンジニアが不要になるわけではない、私はそう思うのです。

そもそも「インフラエンジニア」の定義が曖昧ですけどね。
ちょっとウィキペディアを調べてみましょうか。

インフラエンジニア - Wikipedia

情報システムの構成要素には様々な技術が使用されているが、H/W、仮想化、OS、ネットワーク、ミドルウェア、セキュリティといった基盤となる領域を担当するのがインフラエンジニアである。インフラエンジニアのカテゴリには各要素技術に精通したITスペシャリストやサーバーエンジニア、セキュリティエンジニア、プラットフォームエンジニア、ネットワークエンジニア、データベースエンジニア等が含まれる。 次にネットワークエンジニアを調べてみましょうか。
ネットワークエンジニア - Wikipedia
結構、のあることが書いてあります。

一部の零細請負企業ではネットワークエンジニアへの登竜門的業務と位置づけている場合があるが、ルーチンワーク化によってネットワーク技術に一切精通していなくとも勤まる現場も少なくなくスキルを身に着けられない可能性がある 1990年代後半にインターネットが爆発的に普及した事による慢性的な人材不足のため、技術職にも関わらず文系出身者も少なくない。 これは多くの一般企業において、"ネットワークエンジニアと称されたポジション"が、コンピュータ・アーキテクチャやソフトウェア工学を修得せずとも携わることができるという、各国では類を見ない日本特有の慣例があるためと考えられる。 いわゆる理系コンプレックスを持つ者が、IT業界におけるエンジニアを目指す上で、本人にとってソフトウェア工学などが一種の鬼門として存在していた場合、これを回避しつつも「ITエンジニア」というステレオタイプな理系像を身にまとうための格好の職業として、"ネットワークエンジニアと称されたポジション"を目指す傾向があるためと考えられる。 一般的にパソコンを使用する業務が多く、パソコンをある程度使いこなせれば、未経験でもネットワークエンジニアと称して社内教育を行う企業が多い。

理系コンプレックスって・・・ビーマイベイベービーマイベイベービーマイベイベービーマイベイベービーマイベイベービーマイベイベービーマイベイベービーマイベイベー・・・

サーバーエンジニアとの違い
呼称をあえて分割することにより、従業員が即戦力に至るまでの教育にかかる時間と費用を削減しつつも、OSやミドルウェアの理解が乏しい者がネットワークエンジニアと名乗ることを正当化させる事が狙いとみられる。
言い換えれば、CiscoのIOSのようにOSのバックエンドを極力ブラックボックス化し、高度に抽象化された独自のシェルを実装してユーザーに機能の全てを提供する事で、情報処理技術のリテラシが乏しくとも取り扱いが比較的容易なシステムと、そうでないシステムが境界区分として扱われがちということである。
よって、日本では一般的なIAサーバ等にて稼動するOSおよびサービスについてはネットワークエンジニアの守備範囲外として扱い、設定のすべてを独自のUIで完結できる性質の装置はネットワーク機器として分類して業務が分担されるという、歪な労働実態が存在する。

・・・何か恨みでもあるのかと思ってしまいます。

さて、何故、インフラエンジニアが不要にならないかに戻ります。

そもそも「クラウドにしたからインフラエンジニアは要らない」と言われてしまうインフラエンジニアは、これまでにどんな仕事をしていたのか。

クラウドだろうが何だろうが、障害というものは起きるときには起きる。確かにファイブ・ナインを金で買うことはできるかもしれない、しかし、その上で動いているアプリケーションがファイブ・ナインの品質にあるかは別の問題だと思います。

何か起きたときに経験の引き出しを活かし、想像を巡らせ、想定原因をいくつかあげて復旧を目指す、そこは同じ。多少、ソフトウェアがどういう仕組みで動いているかを理解することも必要になるし、ミドルウェア周辺の知識も必要になると思うけれど、そんなもの学べばいい。そういう意味では主流の技術のサイクルが速いソフトウェアエンジニアのほうが身軽というかタフなのかな。学ばないと死ぬし。

つまり、要らない、と極端なことを言われて、落ち込んだり、不貞腐ったりするエンジニアはそもそも、その程度の仕事しかしてこなかったということなんじゃないかと思うわけです。クラウドにしたから、インフラ系の技術が不要になることはないということ。むしろ、仮想ホストにアクセスできなくなるぶん、インフラに対するより深い洞察のできるエンジニアが必要になるんじゃないかと。手が出せないこともあるかもしれないけれど、サービス提供者のサポートや開発者、メーカー、そしてお客様とのコミュニケーションや解決の道を探る工程には変わりはないと。

そして、もうひとつ、先にも書いたけれど、どこぞのクラウドだからとか、その企業が展開するクラウドサービスと同等のSLAが得られるわけではないということ。クラウド基盤の上で動くプログラムコードが稚拙なロジック、つまり、ウンコードが走っていれば、当然、SLAなど期待できないわけです。

最近、多いんだよな、口の達者の兄ちゃんが「AWS側の問題です(キリッ)」って、そもそも英語屋や手配師もどきのSE(セッ)に技術的な説明なんて求めていないわけで、AWSをブラックボックスの盾にして、ウンコードの問題を隠蔽しようとする、その手口に心底ガッカリするわけです。

まあ、その前の世代は、宇宙線の問題でシステムダウンしました、なんて、ワケワカラン世界もありましたが、まあ、極東の島国で起きた障害なんてどうでもいいんでしょう、とか、ああああ、愚痴をこぼすと止まらないので止めときます。

えーと、あと、言いたいことは、クラウド上での開発にはクラウドならではの仕様を前提とした設計と実装が必須であるということですかね。「貴社(貴様)のオンプレミスのサーバをそのままクラウドに移行します」なんて言っちゃっていいのかな、と。できないことはないんだろうけど、オンプレミスでは遭遇することのなかったトラブルに見舞われるぜよ。あいつとか、あいつとか、あいつとか 笑。

・・・自戒を込めて。


RECENT POST「技術コラム」の最新記事


技術コラム

Sumo Logic Collecterの設定移行の方法  

技術コラム

サイバーセキュリティとレイヤーディフェンスについて

技術コラム

Pulse Connect Secureの脆弱性(CVE-2021-22893)について

技術コラム

Azureの仮想マシンへ脆弱性スキャンしてみる ~その2~

インフラエンジニアのぼやき