インフラエンジニアは死んだ yapc -asia 2014

インフラエンジニアは死んだ

YAPC::Asia 2014 TOKYOAugust 29, 2014Satoshi SUZUKI

Me

鈴木哲詩

インフラエンジニア

Rubyist

LINE株式会社

この定義なかったことにしてください

今日お話させていただきたいこと

プログラミングスキルのないインフラエンジニアは

死ぬの？

今日お話させていただかないこと

フルスタックエンジニアに

なろう！

インフラエンジニア

と

プログラミング

インフラエンジニア

と

プログラミング

インフラエンジニア

と

プログラミング

インフラエンジニアコードを書かない

コードを書けない

インフラエンジニアに付けられたラベル

大多数の

インフラエンジニアが

該当している？

WEBであれだけ言われてるくら

いだし

インフラエンジニアコードを書く

コードを書ける

インフラエンジニアに付けられたラベル

カッコイイ

スゴイ

ちょっと

考えてみた

そして

色々やってみたので

その話を

します

と、その前に

プログラミング

と

あたし

プログラミングとあたし

プログラミングとあたし

C++, Java, PHP などやってみたけどモノになる前に挫折した期

プログラミングとあたし

今日の話はココらへんのところ

インフラエンジニアって何する人な

の？

WEBサービスのシステムスタック

インフラエンジニアの担当領域

インフラエンジニアの担当領域

インフラエンジニアの担当領域

インフラエンジニアの担当領域

WEBサービス

に限定しても

これだけ多様

今日の話の中のインフラエンジニア

特に注記などない場合WEBサービス開発の現場で

ココだけを担当している人たちを主に指していると思ってください

インフラエンジニアの今後

ハードウェア

データホテルさん、ハートビーツさんのようなところに運用の一部または大部分をお任せ

・自分でする機会が減る

・ネットワーク関連

・システム障害の一次対応

・ハードウェア障害対応

例えば

クラウド

AWS、GCEのようなクラウドを利用する

・AWS SDKなどを用いた運用システムの構築

・ハードウェアを基本的に意識しなくていい

例えば

Nagios

言わずと知れた(?)、OSS監視ソフトウェア

・プラグインによる拡張が柔軟に行える

・なきゃ自分で書ける

・コードを書けないと拡張出来ない

例えば

Fluentd

言わずと知れた(?)、OSSログコレクター

・プラグインによる拡張が柔軟に行える

・Ruby製だがPerlなど他言語でも拡張可能

・コードを書けないと拡張出来ない

例えば

さらに最近では

・Immutable Infrastructure・Disposable Infrastructure・Infrastructure as a Code

インフラエンジニア死亡

何個かあげてきたように、今後ますますインフラエンジニアもコードを書く事が必要とされる時代になっていくのではないでしょうか？

＼(^o^)／

コード読めない

コード書けない死

今後もずっと

生き残りたい！！

Operation Engineers’

Casual Talks

こんな感じの勉強会をやった

・コード書けないインフラエンジニア、やることなくなって失職するんじゃないの？

・運用系エンジニアでありながら開発もこなせる凄い諸先輩方のお話を聞かせてもらいたい

インフラエンジニアは死ぬ

2012年末も

同じこと

言ってた

勉強会の

内容ですが...

ほげエンジニアの定義について

・自称は自意識に影響を与える

・何を解決すべきなのかを考えよう

・分業は不可能

・ひとまず自分で全部やる

・問題はコードで解決しよう

枕を高くして寝る話

・コードは問題を解決する手段のひとつ

・書かないで解決できるならそのほうが

良い場合もある

・コードを書けばバグがつきまとう

・必要以上に自分だけで頑張らない

登壇者全員が一貫して言っていたこと

・問題は何か

・それをどう解決するか

・問題解決のためになるなら読む

・問題解決のためになるなら書く

Operation Engineers’ Casual Talks

セッションの様子は YouTube にあります

・ほげエンジニアの定義について

・枕を高くして寝る話

Togetter・「おぺかじ」まとめ

インフラエンジニアがコードを読めること

書けることについて

僕が今思うこと

絶対必要

Someone said

・常識的に考えてインフラの知識もコード書く知識も無ければインターネットの仕事出来ない

・apache とか mysql とかの管理してるのに C わからないってマジやばい

・ふつうインターネットのサービス関わってるエンジニアって mysql とか apache とかにパッチ送ったり IOS でルーティングの管理したりワイヤリングとかするよね

とは言え

・いきなり Apache とか MySQL をソースコードレベルで理解するとか無理

目の前にある解決すべき問題は？

・Apache とか MySQL のソースコードレベルでのチューニングではないはず

解決すべき

問題は

何なのか考える

目的を果たすためにコードを書く

・求められている役割

・目の前の問題はなんなのか

CloudForecast, GrowthForecast, HRForecast, Kurado, Yabitz, Shib, Whada, Norikra, fluent-agent-lite, Ikachan, Nata2

いざ

必要になったときに

実際に手を動かせるか

名称にまとわりつく

先入観に惑わされてはいけない

インフラエンジニアコードを書かない

コードを書けない

インフラエンジニアに付けられたラベル

インフラエンジニアコードを書く

コードを書ける

インフラエンジニアに付けられたラベル

カッコイイ

スゴイ

結論は結局

インフラエンジニアは

コード書けないと

やべーぞってこと？

否、ではないけど...

・インフラエンジニアがコードを書けないからヤバイのではない(本当はヤバイと思うけど)

・ヤバイのは世間にあまねく◯◯エンジニアは

■■をしないという先入観

インフラエンジニアだから(する|しない)ではな

い

運用するそのサーバで

動いているものは

すべてがプログラム

だということ

どのように

習得したのか

入門書レベルの

シンタックスの理解

くらいまでは

自分の力だけで

どうにかする

とにかく

書いた

Fluentd

僕がプログラミングをきちんとはじめなければならないなと思うようになったきっかけになってくれたプロダクト

・はじめは out_exec_filter と Perl でアプリケーションのログの解析っぽいことをやった

・Ruby を始めてからは plugin も書いた

業務で書く書く書く書く書く

既存システムを置き換えるコードを書いては

つぶしてってことをずっとやってた

・転職してすぐのころはこんなんばっかで

まったくバリュー出してなかった

・許されていたわけではなかったけど

やらせてもらえた

とにかく

読んだ

OSSコントリビュータが周囲に多い

普段使っているソフトウェアの中でCloudForecast, GrowthForecast, HRForecast, Yabitz, Whada, Fluentd あたりを結構読んだ

・作者やコントリビュータが身近にいる

・わかんなかったら聞ける

・改修の相談もしやすい

とにかく

見てもらった

天才のコードっぽいって言われた

/proc/meminfo をパーズするコード

・超真面目に書いた

・今見たら普通にオカシイ

天才のコードはこうなった

・実装

・コメント

・メソッド名

コメント

・パッと見でわかりづらいところに ・メソッドが期待する入力はどのようなもの であるか ・返す値はどのようなものか

命名

長くて冗長かなという感じになってしまってもわかりやすい名前をつける

convert_memory↓convert_memory_human_readable

命名

・日本語で「◯◯するやーつ」で命名

・「◯◯してから△△するやーつ」とかになってたらそのメソッドやクラスに仕事をさせすぎかも知れないと疑って分割出来ないか考える

・それから英訳する

教わるときに気をつけてること

・言われたとおりにまずはやってみる

・自分は未熟すぎるとの自覚

・諸先輩方が言ってることを素直に信じてみる

教わるときに気をつけてること

・疑問に思ったことはちゃんと聞く

・「あのときはこう言ってました」

・「過去の自分は他人」

・「....」

OSSにコントリビュート

※ コントリビュートと言っていいかどうかは...

fluent-plugin-flatten, rewrite

・タグが書き換わらないと内部で無限ループ

するバグの修正をやらせてもらった

・コーディングスタイルや、どういうふうに

実装してくと良さそうということを具体的に

細かく教わった

Serverspec

・機能追加の pull request をした

・バグ報告、修正の pull request をした

・実装のアドバイスをしてもらった

動作確認不十分なまま pull request 出して怒られたことも...

ソースコード

リーディング会

ソースコードリーディング会

・ほんの最近始めたばかりだが

・実際にプロダクションの実装をしてる人に

解説してもらいながらみんなでコードを読む

・プロダクションの実装に対して当事者意識が

芽生えてとてもいい

仲間を

増やそう

ひとりで頑張るのはつらい

僕がプログラミングを習得していった流れから読み取っていただけたかと思いますが、

僕は本当に仲間にめぐまれました

刺激を与えられる

刺激を与えられる

まずは自分を知ってもらう

こういうカンファレンスに来ても、どこの誰で何してるかわからないと仲良くなりづらい

・ブログ書く

・勉強会で発表

仲間を

見つけたらISUCON出よう

結論

結論

インフラエンジニアとして

目的を達成していくためには

プログラミング習得は必須