こんにちは。「ふいんき」と書いて「なぜか変換できない」の流れをやろうとしたらgoogle日本語入力だと余裕で変換できてしまい、沸き起こる複数の感情と戦っているhiroshiです。
去る2011/06/25(金)、DevOpsカンファレンスという勉強会でスピーカーをやらせてもらいました。そのお礼と、お話の補足をさせていただこうと思います。
勉強会での発表は社を代表した内容にしたつもりですが、このエントリは、けっこう個人的な想いを多めにしてますので、もし異論反論ありましたら@hiroshi19790209までください＞＜。
去年末の「ZABBIX勉強会」以来のスピーカーで、あのときの参加者が60人くらい、今回も最初は80人くらいの募集だったから「実際くるのは応募人数の8掛けで60人くらいだろうから、このくらいの人数だったら経験済みだぜ！」と思って立候補したら、参加枠が120人まで伸びた上に当日もほとんどまんま120人近くの方が参加してきて、@marqsさん恐るべしな感じでした。
謝辞
@gosukenatorさん、「こんな感じの内容であってるのかなぁ」、とビクビクしていたのですが、「カルチャー」の話のおかげで、気楽に話せました。気楽過ぎたかもしれません＞＜
@riywoさん、僕もシャイボーイなのでちょっとしかお話できなかったです。またゆっくりお話したいです。
CAのみなさん、会場提供・設営などお世話になりました！
ご参加くださったみなさん、ご清聴ありがとうございました。あえて苦言を呈させていただくと、カイジをご存知のかたは「圧倒的閃き・・・！」のところでもっと笑ってもらいたかったです。
お話の補足
僕は今回、せっかくだから楽しいほうがよかろーと思ったのと、根がシャイボーイなのでああいう感じじゃないと恥ずかしくて話せないので、結果ネタっぽい感じになってしまいましたが、本筋を外したつもりはありません。
すべては
それはみんながよろこぶことなのか
というところにつながります。
そして、「みんな」とはユーザーのみなさん、クライアントさん、協業さんだけでなく、自分たちも含んでいます。「自分たち」です。「自分」じゃありません。でも「自分たち」の中には「自分」も含まれています。
僕たちは別に少数でやることがポリシーなわけでもなんでもないので、これはただの制約にしか過ぎません。
この制約の中でサイトを安定させるだけでなく、進化させていかなければなりません。
って、そんなのどこだって同じ、あたりまえの話だと思うんですよね。6人が多数か少数かは状況によって違うわけで、人手なんてどこももっと欲しいと思ってると思います。
だから（人手の募集はなんとかするとして）そんな中どうやったら一番アウトプットが最大化するか、っていう話なんだと思います。
それを僕達は、6人いるメンバーをDevに寄らせたりOpsに寄らせたりしてやっているつもりです。
アウトプットを最大化するためにはいろいろなアプローチがあると思います。
- 作業の効率化（自動化）
- タスクの取捨選択
- アウトソース
- 情報共有
- etc..
それぞれの中で
- やらなければいけないこと
- やるべきなこと（ベキ論的な意味で）
を冷静に見極めなければいけないと思っています。
特にIT界はベストプラクティスと言われる「あるべき事例集」みたいなものがたくさん流通している気がします。
僕の心が汚れているせいだとわかっていますが、それらからはなんとなく「これをやらないから、おまえんところはデスマになるんだ！」的なオーラがただよっているように思えます。
※それを提唱している人や、推し進めようとしている人からでているオーラではなく、ただ単に僕の汚れた心がWeb上あたりからそういうオーラを感じているだけです。念のため。
が、それらはすべては考え方の話で、前提条件が揃わなければそれは最高の選択肢でありうることは少ないと思っています。
※提唱している人や、推し進めようとしている人は、考え方の話をしているはずです。
特に収益を得ることの手段としてのITであればなおさらだと思います。
たとえばテストは書くべきだと思います。テストは拡張性、保守性、可読性を高めます。確実に入るであろう今後の変更を考えたらやらない手はありません。でも、常に今後のことを考えた選択肢が正しいとは限らないと思います。「今、ここで、リリースできないと今後なんかない！」というノリの状況は少なくないと思っています。そんな状況ではTDDの採用は正しいとはいえない選択肢だと思います。（テストを書いても開発スピードが落ちないという人しかいない場合を除く）
「今、ここで、リリースできないと今後なんかない！」という考え方を理解しようせず「TDD!TDD!」とか言っている人は、ユーザーのよろこびに比べ、自分のよろこびにかなり重きを置いている、といえると思います。
そして、よろこびが偏った選択肢は、サービス全体として非効率な選択肢になります。
DevとOpsの対立みたいな話の具体例は残念ながら(?)うちにはありません。DevとOpsの分けがないから。
でもサービス開発にあたって、技術チームとディレクションチームといった分けはあります。この分けも、「同じものを作ってるけど、やっていることがちょっと違うチーム」といった意味ではDevsとOpsの分けとそう性質は変わらないと思います。
が、やっぱり対立みたいなものはありません。
きっとお互いのことを尊重できているからだと思います。
同じものを作っているのになぜ対立が起きるのか、はいろんなきっかけがあると思いますが、たぶん会話が足りないからじゃないかなと思います。
「わかるけど、そうコトはシンプルじゃないんだよ」と言う人もいるかもしれませんが、もうこれくらいしか推すアイデアがないんです。
同じサービスを支えているのに対立するって、おかしいじゃないですか。
会話といっても、酒場に行って飲むとかだけじゃないと思うんです。
なんだったら、DevsとOpsで短期交換留学みたいのしてもいいかもしれないです。
今回のDevOpsに参加された方しかわからないかもしれないですが、家族の理解の件ででてきたBBQの話もこれと同じノリだと思ってます。
ところで、家族の理解の話は、「アラートの監視体制は全員。深夜休日は当番制」といった体制から「家族の理解が得られるのか」といった質問がきたと記憶しており、BBQの提案をついしてしまいましたが、そもそもうちのアラート運用はそんなきっつい運用であると思っていません。
発信されるアラートの閾値や種類の出しワケなど、工夫を重ねていけば、少なくとも家族の理解の話になるような事態にはならないと思っています。
たとえば、ハード障害とかは無理ですけど、同種のアラートはきっちり対応していけば確実に減らせます。
@riywoさんもプレゼンの中でおっしゃっていましたが、それをきっちりやると、本当にメールを見ただけで障害の内容がだいたいわかるようになってきます。
なので、現在のDECOLOGではそのルールがキツイといった状況ではないと思っています。
少なくとも、うちのredmineの数あるタスクの中には「改善するべき」というチケットは切られていません。
冒頭で「みんなよろこぶの『みんな』には自分たちも含まれる」と言ったように、もし、このアラート運用が実際キッツいものであれば、全然ダメダメだと思います。
アラート受け取る側が多くの犠牲を払って成立するサービスなんてどうかと思います。
スライドでは「よろこびの最大化」といったことも書きましたが、これはみんなのよろこびを数値化したらもっとも大きい選択肢を採るということではないです。
最近マイケル・サンデル先生の「これからの「正義」の話をしよう」という本を読んでいますが、この中にオメラスという町の話がでてきます。
"オメラスではすべての人が飢え、貧困、病気もなく、幸せに暮らしているが、その幸せはたった一人の子供が窓もない地下に閉じ込められていることが前提となっている"
といった町です。
こんなの絶対ナシだと思っています。速攻で改善です。
あと、長期的な自己犠牲も禁止です。ダメ。
そんな選択肢を採らなくても、みんなの知恵で工夫を重ねることができれば、一時的にはつらいことはあっても、DevOps的な問題はだいたいなんとかなるもんだと思います。
そして、みんながよろこぶ選択肢を選び続けていれば、たった数人で数十億PVのサイトを運営していても、それなりにやりたいことができる環境が作れると思います。作れていると思います。今のところ。
ここまでの話の具体例とかは、どうしても自分が今WEBサービスをやっているので、その視点になってしまいますが、WEBサービスじゃなくても同じことだと思います。なんならITじゃなくても同じだと思います。
DevOpsのあとがき的な内容として、あっているのかだんだんよくわからなくなってきましたが、言いたいことは言った感はあります。ほんと、すみません。
最後に、会場設営のときのCAの方がたの若々しいふいんき（変換できるけど変換しない)はなんとも楽しそうな感じで「こういうふいんき（ry）が大事なんだよなーって思いました。今度飲みに誘ってください。ということをもって僕の挨拶とかえさせていただきます。
おわり。