読者です 読者をやめる 読者になる 読者になる

情緒不安定。

WEBサービスのインフラ担当SEの仕事・趣味の記録です。

エセインフラエンジニアの焦り(訳 qpstudy 2016.04 響け!アラートコール! の参加しました)

運用 勉強会

2016.04.23@西新宿ニフティさんで開催された、qpstudyの勉強会に参加しました。

f:id:ls-ltr:20160506110725j:plain

はじめに

勉強会のwarp upの通り、ブログを書くまでが勉強会!ということで、各セッションで感じたことを、私の焦りを書いてみます。覚書みたいになり、読み辛いかと思いますが、よろしくお願いします。
あーこういう残念なエンジニアもいるんだなと知っていただければ幸いです。

エセインフラエンジニアの背景

  • 20代男性
  • 金融関係SIer
  • リリースしてドキュメント納品しておしまいではなく、保守まで一括して受託している会社で働いています
  • 社内ポジションはインフラ担当(Dev&保守運用)
  • Devでの自担当範囲は、要件定義から詳細設計までと試験から移行。インフラ担当のため、基本ベンダさんの進捗管理がメインとなっているのが実情
  • 保守運用範囲での自担当範囲は、顧客からの照会、定期的な各種リソース状況の評価、障害発生時の切り分け調査
  • 夜勤監視はしてません、夜に起こされる系男子
  • 業務でプログラミングしたことない(必要となればbashDOSコマンドでbatを少々レベル)
  • 未だにベンダ営業に電話しちゃうタイプの人間
  • 懇親会は残念ながら不参加勢
  • ると (@karoot) | Twitterの人

発表を聴いて

その1「インフラ監視の今後を考える」
speakerdeck.com
その2「Re: 運用に自動化を求めるのは間違っているだろうか」

www.slideshare.net

勉強会の経験が浅い私には、全体的にモヤモヤしているなというのを感じました。(後に控えたグループディスカッションのためでしょうか)
「なぜ監視をするのか?」の問いかけに、「しないといけないから。お客さんの要望でしょ。」と反射的に思いましたが、後々のディスカッションの中で監視するコスト<障害による損失だから監視をしているという当たり前のことに気づきました。自社内でもランニングコストを安くすませるために、監視をしていないシステム、松竹梅で監視のレベルを業務要件に応じて提案&実装しているシステムが身近にもありました。(他の人もおっしゃっていましたが、監視レベルの松竹梅の段付は、システム担当のエンジニアやプロマネの経験則に依存していることが多いかもしれません)

運用自動化については、私の携わっている金融システムでも徐々にきています。最近だと、パニックからのOS自動再起動復旧→サービス稼働確認→商用利用開始などは自動化の仕組みを構築しました。(私達の説明が行き届いていないのもあり、お客様システム担当は自動より手堅い実績のある手動でというと流れが残っているのも事実です。)

脱・刺身タンポポ、脱・写経文化という中で、こんな*1
記事を書いてしまう、また要点をサラサラと書けてしまう自分の業務は、世の中から数十年遅れていると痛感しました。

グループディスカッション

・他の班にもちらほらいましたが、金融系って精神的にも物理的にも独自の進化を遂げているなと痛感しました。
・どこかのチームで前提として発表してましたが、話し合う前にお互いの監視対象のシステムの概要、規模だけ意識合わせすればよかったと。
・運用/開発の温度感の問題はどこも陥りがち。
・自動化は手段でしかない。目的の明確化、メリット感をアプローチできる人が社内にエバンジェリスト的存在?が必要

焦り

私が業務でしていることは開発メインだと思ってたけど、半分は世の中的に言う運用に片足を突っ込んでいて、物理的にも精神的にも現在閉ざされた環境だからこそ生きていけるエンジニアなのではと認識しました。
今後、金融業界のfintechによるオープン化、PaaSやdockerなどを活用したDevOpsという新しいアプローチ、インフラの家畜化(リソース仮想化に伴う死んだサービスは放置し新たに作る風潮)により、閉ざされた環境が崩壊。このままだと、私の領域は自動化され、お給料はなくなり死に絶える。私の会社が体制が(笑)とか、金融だから(笑)と飲み会の席で愚痴を言っている場合じゃない。

インフラが変革してきている今、オン/オフで惰性で吸収してきた様々な技術ノウハウを一度見つめ直し、早めに方向性を決めていかないといけない。

総括

拙い文章を最後まで読んでいただき、ありがとうございました。私にとって、社外の利害関係のない方との初グループディスカッションでしたが、上記の様な焦りを感じることができ、とても有意義半日でした。
またどこかでお会いする際・本Blogコメントで、ご指導のほどよろしくお願いします。

NextAction

  • デプロイを実際にしてみる
  • 人間でしかできないことを武器にする(メトリクス、予兆検知)
  • 得意なネットワーク範囲を深くする(SSL/TLS,SMTP,DNS)
  • AWS/Azureの環境構築
  • SlackAPIへ自宅のサーバやAWS/Azureから連携

ご参考

本記事を書く中で拝読させていただきました、素敵な記事の紹介をさせていただきます。中間管理職的なインフラエンジニア?な人、是非読んでみてください、とてもいい刺激になると思います:-))

インフラエンジニア(狭義)は死んだ - YAPC::Asia Tokyo 2014
インフラエンジニアの幸福論 · the world as code
[インフラ] インフラエンジニアの将来は明るいのか:その1 [アプリ] – oshiire*BLOG
[インフラ] インフラエンジニアの将来は明るいのか:その2 [アプリ] – oshiire*BLOG