オペレーションエンジニアとは何かを理解するために「ウェブオペレーション」を読んで欲しい

最近は、@kazeburoさんの真似をして自分も「オペレーションエンジニア」と名乗ろうかと思ってます。正直最初にオペレーションエンジニアって聞いた時、なんのことだかよくわからなかったんですよね。ちょうどこの言葉を最初に見たのは1年前くらいで、その時僕は2年目に入ったところでMySQL Conferenceから帰ったばかりで「おらはDataBase Administrator(DBA)なんだ!」と思ってた頃でした。

それからちょうど1年。1年目の時もDBだけをやってたわけではないですが、この1年はより広くより深くいろんなモノを見てきた関係で、自分の仕事は「DBA」だけだとちょっと説明に足りないなぁと思ってたところで、「オペレーションエンジニア」という言葉を思い出しました。そう、僕の仕事は「オペレーションエンジニア」なんです。ひよっこだけど

ん、ちょっと待てって?「オペレーションエンジニア」って何なのか、結局説明がなかった?フヒヒ、もはや僕ごときがそれを説明する必要がなくなったのですよ。「オペレーションエンジニアとは何なのか?」を必要十分に網羅的に説明してくれる良書が手に入る様になったから!僕が構造化して説明する必要はもはやないッ!!

とりあえず読んでみた

というわけで、つい先日日本語版が出版された「ウェブオペレーション」を急いで読みました。感想を先にまとめると以下の通り。

  • 僕らのやってることはまさにオペレーションエンジニアだと確認できた
    • ついでに本場のやってることとそこまで乖離してないと確認もできた
  • すでにオペレーションエンジニアやっている人は黙って読めば良い
    • 所々、涙が出る(主に過去の体験を思い出して)
    • これは仕方ないがいくつかは宗教上の理由により(ry
    • 第2版には自分がここに寄稿できるように切磋琢磨しよう
  • 開発エンジニアをやっている人はお願いだから目を通して欲しい
    • 我々の混沌とした仕事を、1つのわかりやすい説明として紹介してくれている多分初めての書物
    • オペレーションエンジニアが何を考え、どう行動しているかをふんだんな実例を読むだけでも少し体験できる
  • 新人はこれ読んで泣ける様になったら一人前(嘘

なんか大体書けてしまった。でももうちょっとつっこんで感想をば。引用多めでいきます。

まえがき、、、お前、、、いいやつだ

なによりもまえがきが泣ける。全文を引用したいぐらいなんですが、賢明な読者ならもうここでAmazonをポチっとしてくれているでしょうから絞って紹介しますよ。ハンカチの用意はいいですか?

みんながローンチ記念パーティに参加するなか、我々はデータセンタの奥深くで最後のサーバを設置して、夜更けに自分のデスクに戻り、流れ行くログファイルとグラフの輝きで顔を照らすのだった。

p.vii

(´;ω;`)ブワッ

我々の経験は共通していた。ソフトウェアは普通にクラッシュした。スケールなんてしなかった。データベースは当たり前のようにクラッシュしてデータをふっ飛ばした。(中略) 我々がサイトを元に戻すと、開発者が新しい機能を追加して、トラフィックが急増した。そしてすべてが壊れた。

p.vii

(´;ω;`)ブワッ(´;ω;`)ブワッ

ウェブオペレーションは技芸であり、科学ではない。正規の学校教育・資格・標準は(少なくとも今はまだ)ない。(中略) 「正しい方法」はどこにも存在しない。そこにあるのは。(とりあえず今は)うまくいくという事実と、次はもっと良くするという覚悟だけだ。

p.viii

(´;ω;`)ブワッ(´;ω;`)ブワッ(´;ω;`)ブワッ(´;ω;`)ブワッ(´;ω;`)ブワッ(´;ω;`)ブワッ

。。。涙はここまでにしよう。そう、この「共通している経験」を一貫して紹介していくのが本書なのです。しかもある程度体系だてて。

まえがきにある通り、僕も「ウェブオペレーション」についての教育は整ったものとは思えません。開発エンジニアのやっていることについては、趣味のプログラムでもある程度は体験できるし、複数人での開発というのもCS系の学科だけでなくいくらかの学科ではすでに授業としてすらやっているようですね(もちろん現場の最前線とは差はある)。それに人数も多い分、ナレッジも溜まるしいい意味で流出しやすい。

一方オペレーションエンジニアのやっていることはなかなか理解されない。相手がCS系の学生であったとしても、毎晩の様にアラートメール・電話でたたき起こされることに快感を覚えている僕達がなんで存在するのかはなかなか理解されないでしょう。コンピュータが間違うはずがないと思っていた時代が僕にもありました。僕は幸運にも、入社してすぐにえらく高トラフィック&急成長している現場を任されたので、それらが間違っていたとすぐに思い知らされました。

僕は現場の叩き上げで身につけたけど、みんながみんなそんなことしてる時間はない。その意味で、本書は僕らオペレーションエンジニアがどういう考えをしているのかを手っ取り早く理解できる良書だと思います。だからこそ、オペレーションエンジニアだけでなく、すべてのウェブエンジニアに目を通してもらいたいです。と若造が言ってみる。

各章は「失敗例」がふんだん

その後各章はそれぞれの寄稿者によって1つのテーマが語られています。ほとんどの章がふんだんな「失敗例」を紹介しているのが特徴的です。その中でも特に印象的なのは「6章 監視」。

「夜中にアラートがあっただろ。2時に25通も来たんだぞ!原因は同じなのに25回も対応しなきゃいけなかったんだ!(中略)そしたら今度は4時だ。pingのエラーが1分おきに飛んでくるんだよ!(中略)もっとまともなものにしてくれよ」

p.77

オペレーションエンジニアにとっての監視は、開発エンジニアにとってのテストだと僕は思っています(kazuhoさんの受け売り)。監視は大事。ふんだんな「失敗例」をもとに監視とはなんぞやということを説明してくれています。斜め読みしただけなので、僕もあとでじっくり読み返したいです。

また、「9章 予期しないトラフィック急増への対応」は、急成長することを期待されているスタートアップのサービス運営者にとっても、とてつもないリリースを控えている大規模サイトの運営者にとっても示唆に富む話が紹介されていいます。

メインのデータベースサーバから応答がないと知らせてくれたのだ。(中略) 何が起きているのかわからなかった。データベースサーバにはクエリの負荷がかかっていた。すべて同じクエリだった。それでわかった。フロントページのコンテンツのキャッシュを生成するクエリだ。しかし、なぜそんなにたくさん実行されているのだろうか?すぐにチーフ編集者からYahoo!の紹介記事の話を聞いた。

p.101

そして、僕がなによりも涙したのが「10章 開発と運用の協力と連携」でした。

ウェブシステムはある程度規模が大きくなってくると、どうしても「開発」と「運用」が疎遠になってしまいがちです。その中で重要なことは「信頼」だと紹介しています。まったくもってその通りだと思う。別にケンカしたくて(椅子を投げたくて)仕事してるわけじゃない。会社を、事業を、大きく成長させたいとみんな思っているはず。

誰もがもっともらしい理由をつけて誰かを非難する。しかし、自ら修正しようとする人は誰もいない。(中略) 自己弁護をする時間は、ユーザにとってサイトが壊れたままの時間である。(中略) 何か問題が起きたときは、責任をなすりつける人を探すよりも、問題を探す方が簡単だということだ。(中略) こうした態度は周囲に伝染する。問題を解決しようと努力すれば、みんなが手伝ってくれるようになる。(中略) 自分のシステムに問題がないとしても、腕をまくって調べる態度が人を動かすのである。

p.120,121

まさにこれを僕は何度も体験しています。僕は何も知らない初心者だったけど、とにかく問題を解決しようとすることにだけは必死で取り組みました。ない知識を振り絞って、足りなければ聞いて、調べて、全力を尽くしていると、自然とみんな助けてくれる。オペレーションエンジニアにとって、どんな些細な情報でもインプットをもらえることは、それだけ問題を分析する精度・速度が上がることになるので本当に助かりました。そしてみんなのおかげで僕はここにいます。これからも互いに協力して刺激しあって成長したいと思っています。

まとめ

このぐらいにしましょう。わざわざ僕が語るのは不遜というもの。ともかく手にとって読んでみて欲しいです。細かい技術話がわからなければ、実例の部分だけを流し読んでもいいと思う。それだけでもいい疑似体験になります。

僕個人の話をすると、6月にシリコンバレーで開催されるVelocity Conference 2011に参加する予定なんですが、編者の2人はVelocityに大きく関わられていたり、内容的にも本書とVelocityは丸かぶりなので、すでにwktkが止まらないですね。もしもピアノが弾けたなら英語を書くのが速ければ、このエントリを英語で書いてみたかった(時間があればやりたいけど多分ない。。。)。

というわけで、久々に「これはとりあえず読んどけ」という技術書に出会えて興奮した次第でした。是非是非皆様お試しあれ!

著者、編者、訳者の方々に多謝!( ;∀;) カンドーシタ

Johann 11-05-18 (水) 0:51

僕自身はシステムエンジニア(オペレーションサイド)から開発側へ移りつつあるんだけど、今のところ開発者の方がいいなーと思っている。

オペは給料安いし、夜中のオンコールがあるケースも多いし、自らの手でモノを作ることができない。加えて、直すにも結局開発者に連絡しないと詳細が分からず直せないことも多い。

riywo 11-05-18 (水) 1:49

> Johannさん
どっちがいいかは人それぞれでしょう。

給料安いはあなたの周りだけの話かも知れませんし、モノを作れないというのも、連絡しないと直せないというのも、100%いつもそうではないはずです。

いずれにせよ、両方よく知っている方がどっちをやるにもメリットが高いことは事実だと思いますのでご活躍を期待しています。

ばしくし 11-11-26 (土) 5:19

新卒でSIerに入り、金融インフラの仕事をやってました。Pro*CとOracleとAIXとJP1の日々…まあ保守・運用ですね。
で、その後部署が移動し、LAMPのPerlでアプリ開発をガリガリと。
その後社内SEとして自社の社内システムリプレイス案件のPMをやった後で
開発を思いっきりやってみたいため、ベンチャーへ転職。
そこでPerlに加えて、Symphony(PHP)やDjango(Python)も覚えた後、思うところがあり退職し
一般派遣としてNW/サーバ構築の案件に手を出す。男だらけのムサい職場でガチガチにやってます。
インフラ系の設計・構築をまともにできて、且つそれなりに話ができるプログラマブルな派遣って、超人材不足らしいんですね…時給3500円はおいしいッス。
でも、いつまでもこの業界の案件受注で飯食ってるわけにはいかんですよ。身が持たん。
そもそも、月50万も売上げれば、個人としてはそれだけで食っていけるんだから
わざわざ会社でシステム作ったり、運用したりする必要なんてないような…と思ったりするわけです。
こんなこと考え出すようじゃ、そろそろこの業界も上がりかな…アイデア作りのための刺激がほしい今日この頃。