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

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

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

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

• 『ウェブオペレーション―サイト運用管理の実践テクニック』という本を訳しました。 – capsctrldays(2011-04-27)

とりあえず読んでみた

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

• 僕らのやってることはまさにオペレーションエンジニアだと確認できた

  • ついでに本場のやってることとそこまで乖離してないと確認もできた

• すでにオペレーションエンジニアやっている人は黙って読めば良い

  • 所々、涙が出る(主に過去の体験を思い出して)
  • これは仕方ないがいくつかは宗教上の理由により（ｒｙ
  • 第 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 万も売上げれば、個人としてはそれだけで食っていけるんだから
  わざわざ会社でシステム作ったり、運用したりする必要なんてないような…と思ったりするわけです。
  こんなこと考え出すようじゃ、そろそろこの業界も上がりかな…アイデア作りのための刺激がほしい今日この頃。