・公式サイト
http://event.shoeisha.jp/devsumi/20130801/
・講演関連資料のまとめ
http://codezine.jp/article/detail/7305
場所は渋谷の「ベルサール渋谷ファースト」さんです。
ここ、他の勉強会で行った事あったので道はすぐにわかったけど、なんの勉強会だったっけな。。。
暑すぎて、到着までに全身汗だく。。。
参加者ですが、申し込みの時点で1000人を超えていたとのこと。
大イベントです。
ちなみにテーマはDevOps！
私、自社でDevOps関係のワーキンググループにメンバーとしてちょうど放り込まれたところだったので、今回のイベントはまさしく、渡りに船！
あと、1週間くらいまえに横浜道場で行われた長沢さんによるDevOpsの講演も聴講してきたところでした。
そんとき書いたブログはコチラ。
7/23(火) 横浜道場 特別編 「ざっくりわかる DevOps ～ ビジネスよ！これがおれたちの力だ！」に参加しました http://t.co/qsfISnD5o1
— makopi23 (@makopi23) July 30, 2013
ちなみにこのデブサミには、会社の業務の一環として参加しました。
なので会社への簡単な報告のために聴講メモを書かないといけません。
そんなわけで今更感がありますが、ついでにブログにメモを書くことにした。
あと個人的な復習も兼ねて。
いつもどおり人が読むことは想定せず、自分の復習用にダラダラと書き連ねることとするのであった。。。
講演は丸一日で量が多いので何回かに分けて書きます。今日は「～其の１～ 基調講演」
スライドにない口頭部分を中心に、メモ。
基調講演
DevOpsを実践されている5名のエンジニアによる基調講演です。
■【S1】DevOpsは開発現場とビジネスの間に何を生むか？
・講演者： 新野淳一 氏/長沢智治 氏/浦底博幸 氏/山本正喜 氏/藤井智弘 氏
・URL： http://event.shoeisha.jp/detail/46/session/83/
■新野淳一 氏
■DevOps、国内での盛り上がり（P.3/24～P.4/24）
・国内でDevOpsというキーワードが出始めたのは2010年くらい。
■DevOpsの始まりと広がり（P.4/24）
・DevOpsが登場したのは、2009年にオライリーがVelocityというイベントをやった時。
・この時がDevOpsのキーワードの原点。
・Flickerの講演で「1日に10回もデプロイしている」という話があり、当時、DevOpsは驚きをもって迎えられた。
・それはイイね、ということで次に「DevOps Days」というイベントをやった。これがDevOpsを広める原動力になった。
■最初は相手にされなかったDevOps（P.6/24）
・ここ数年、開発と運用が協力する、という考えはアジャイル系カンファレンスでも相手にしてもらえなかった。
・でも、「DevOps」というキーワードが出てきたことが大事。
■DevOpsの原点を再訪（P.7/24～P.）
・DevOpsの大事なことは、原点である。
→ 原点とは、Flickerの2009年の講演スライド「10 deploys per day dev & ops cooperation at Flicker」。
→ ここに大事なことはだいたい書いてある。
■DevOpsの原点（P.8/24～P.9/24）
・ビジネスは変化を要求してくる。
・でも、変化はリスクを伴う。「動いているシステムに手を入れるな！」という声がある。
・そこで、変化のリスクを下げるために、ツールとカルチャーを使うんだ。
・変化を要求されていないビジネスにはDevOpsを使う必要はないかもしれない。
・ツールだけでもなくカルチャーだけでもない。両方使うんだ。
■カルチャーとは？（P.10/24）
・DevとOpsは仲良く物事を進めていきましょう、という考え。
■ツールとは？（P.11/24）
・ツールを使って以下を実現する。
１．インフラを自動化する。
２．エンジニアの間でソースコードの共有をして、バージョン管理をする。
３．ボタン１つで、バージョン管理されているソースをビルドして、デプロイまでワンステップでできるようにする。
・DevOpsの原点は、カルチャーとしての運用者と開発者の協力と、ツール。
■DevとOpsの言い分（P.12/24）
・両者の言い分はよくわかれる。それぞれ「俺たちがビジネスを支えているんだ」という言い分。
■DevとOpsの協力関係のあり方（P.13）
・カルチャーとツールを使って、互いに協力していきましょう。
■で、うまくいってるの？（P.14/24）
(1) Dev： 継続的デプロイメント
・ツールとして典型的に使われているのは継続的デプロイメント。
・これをしなきゃいけないわけではないが、よく言われているツールと方法論。
(2) Ops： Infrastructures as Code
・インフラをコード/ソフトウェアとして捉える。
-----
・大事なのは、ビジネスの側にとって、それが上手く行っているかどうか。
・DevとOpsが仲良くても、ビジネスが前進してなきゃDevOpsをやる意義は低くなる。
・DevとOpsだけじゃなく、Biz(Bisiness)から見ても上手く回らないといけない。
■メトリクスで判断しよう（P.15/24）
・運用側から出てくるログを解析して、メトリクスを取り出す。
・あらかじめメトリクスを決めておく。
・ログを見て「滞留時間が長くなってるね」とか「バスケットに入れたものがちゃんと購入までいってるね」とか、DevとOpsがメトリクスを共有して判断に役立てること。
■メトリクスはすりあわせが肝心（P.16/24）
・メトリクスを予めDev/Ops/Bizですり合わせておくのが大事。
・「このシステムでは、このメトリクスを向上させるために協力するんだ」という考えを互いにすりあわせる。
・このシステムのログからどんな情報が取り出せるのか、あらかじめ考えておかないといけない。
・必ずしもシステムでログから取り出せる情報だけで評価できるとは限らない。
・メトリクス以外で評価すべきことはあるかも考える。
■エンタープライズでの課題 -日本のSIビジネスにDevOpsは適用できるのか？-（P.17/24）
・DevOpsはFlickerから始まった。オンラインサービスとかスタートアップに近い。
・DevOpsをエンタープライズのSIビジネスにも適用できるのかというと、いくつか課題がある。
・サービスはDev/Ops/Bizの3者が協力しやすいが、SIerだと組織が違ったりとハードルがある。
・でも肝心なのは、ビジネスを前進させることが本質。
・ならば、ビジネス側の人が「DevOpsが大事」だと認識しないといけない。
・DevもOpsも、Biz側に情報を提供しないといけない。
■エンタープライズでの課題 -BizとDev/OpsはDevOpsのメトリクスを握れるのか？-（P.18/24）
・エンジニアがビジネスの要件を把握して、対話して、１つのメトリクスを共有する必要がある。
・エンタープライズは、社内の社員が客かもしれない。
・なので「ログからメトリクスを取り出せるのか」という問題がでてくる。
→ ログ以外のメトリクスを考える必要がある。
■エンタープライズでの課題 -どのプロジェクトをDevOpsで進めるか、選べるのか？-（P.19/24）
・ある程度フォーカスを絞ってプロジェクトを選択する。
・コストとメリットのバランスを考慮して考えていく。
■エンタープライズでの課題 -そもそもアジャイルやクラウドの採用にハードルがあるのではないか？（P.19/24）
・そもそもアジャイルとかをエンタープライズに採用するのに抵抗がある組織が少なくない。
・カルチャーは作れるが、ツールをどうやって説得して採用していくかのハードルがある。
・答えはない。
・こういう課題があることを認識したうえで、乗り越えて行かないといけない。
・このあとのリレートークで議論できればいい。
■山本正喜 氏
■自己紹介（P.2/21）
・ChatWork株式会社は、Webのベンチャー。従業員は30人くらい。
■チャットワークのコンセプト（P.3/21）
・左にチャット、右にタスク管理の画面。
・会話しながらタスクを洗い出して残すことができる。
■DevOps？（P.8/21）
・Dev:どんどん機能追加したい vs Ops:安定運用したい
・この構図は、我々はピンとこなかった。というのも、社内でDevとOpsはあまり衝突してない。
・社内で自然にDevOpsをやっていた。
■CahtWorkにおけるDevOpsの考え方「極力"運用"しない」（P.10/21）
・Dev: １１人
・Ops: ２人
・実質、一人弱で運用してる。
人が少ないとコミュニケーションコスト下がる。
■大規模チャットシステムにおける運用の勘所（P.11/21）
①データベース：
・書き込みが多い。Write-heavy
②ファイルサーバ：
・果てしなく容量が増えるので、どうスケールアウトさせるか。
③リアルタイム通信：
・すぐ発言を相手に届ける必要があるので、ポーリングじゃダメ。
・でも繋ぎっ放しにするとc10k問題に直面する。
→ マネージドサービス（PasSとかSasS）をフル活用している。
■Leanなサーバアーキテクチャ移行（P.15/21）
・プロダクトの成長がある。
・PasSから、それじゃ合わないのでPasS + IasSにした。
・成長にともないIaaSの比率を上げていく。
■障害発生時のフロー（P.16/21）
・基本的に自動復旧
・気づいた人がOpsチームに連絡
→ 自動復旧できたか確認
■ChatWorkにおけるDevOpsの考え方２「DevOps + Biz」（P.17/21～P.19/21）
・ビジネス部門との協力が不可欠。
・全社的に見る必要がある。
■ChatWorkl社で取り組んでいること（実践）（P.20/21）
①ほとんどのコミュニケーションはチャットで。
・メールしない。全部チャット。
・隣にいる人にもチャットで。
・チャットだと全部記録に残る。口頭での「言った/言ってない」が無くなる。
・全員在宅勤務でもいける。エンジニアの集中を妨げない。
②プロジェクトごとにグループチャットを作成し、関係者を全員入れる。
・グループチャットに必要な人を全員いれる。Dev/Ops/Biz問わず。
③タスクの生まれる背景を共有する。
・推測せざるを得ない状況をなくす。
・背景の段階から共有する。それがコツなんじゃないか。
■長沢智治 氏
■ビジネスニーズと戦略的なIT（P.2/22～P.5/22）
・エンタープライズでは、ビジネスニーズからDevOpsがきている。
・ビジネスがITの力を必要としてきている。ITの活躍できる場所は多い。
→ ビジネスを考える上で戦略的なITを考えざるを得ない。ビジネスとITを融合させる。
■エンタープライズでのITの"ユーザ"とは？（P.6/22）
・エンタープライズでのDevOpsでは、ユーザが誰になるかを押さえることが重要。
・コンシューマだけじゃなく自社の従業員のこともある。
■エンタープライズアプリケーションの進化（P.7/22）
・「基礎体力作りをするIT」と「攻めのIT」は別として考えないといけないこともある。
・従来はERPのカスタマイズが中心だったが、これからはブランド力をもって競合他社に勝ち続けるモデルを作る必要がある。
・どこの部分をDevOpsでやるべきなのか見極める必要がある。
■ビジネスにフォーカスした戦略的なIT？（P.9/22～P.15/22）
・課題は「インフラにのせるアプリ」。でも開発の中身がよく見えない。
・ひとつのアプリの状況に合わせるのは難しい。
・DevとOpsが対立構造になることが多い。
■共通ゴール（P.16/22）
・サイクルタイムとMTTRを短くすること。
①サイクルタイム ＝ 企画からリリースまでの時間。
・サイクルタイムの「定期的」という概念は大事。ビジネスパーソンが分かるペースが大事。
②MTTR ＝ 障害が発生したときに普及させる時間。Mean Time To Repair。
・これからは壊れることを前提にしないといけない。いかに早く治すか。
・サイクルタイムとMTTRは両方とも、DevとOpsに関わる。
・ITに近いメトリクスとしては、この２つが手っ取り早い。
・測るには、成果物を共同所有しておくことがポイント。
■DevOpsへの主な課題のポイント（P.17/22）
・昔に比べ、ソリューションは格段に増えた。
・それらをどう使っていくかを考える必要がある。
■MicrosoftとDevOps（P.20/22）
・マイクロソフトでは継続的デリバリをやっている。
・今は３週間単位で作っている。
・DevOpsはパッケージ開発まで波及してきている。
・今まで適用できないと思っていたところでもDevOpsの考えは適用することができるようになった。
■浦底博幸 氏
■Opscode Chef
・単なる自動化ツールではない。
・インフラの姿をコードで定義可能。
・インフラをモデル化してしまおう。
■インフラをコードで定義することで
・コードの共有はチームに閉じない。様々な企業間で共有して、業界全体の品質が上がる。
・TDDが可能になる。
・作業手順でなく、状態を定義する。
■Code Can...
・Opscodeのコンセプトは「CODE CAN」
・コードによって可能性が広がる。戦略性、革新性、可用性、一貫性、堅牢性、etc
■Coded Business
・コードをベースとした文化によって、ビジネスも変わっていける。
■Dev + Ops = Change
・changeを受け入れられるかどうかで日本とアメリカは違う。
■デモ
（省略）
■Q&A
・Chefには3種類ある。
・今回のデモで使ったのはHosted Chef。
・まずはChefを入れて動かしてみましょう。
・ChefはRubyやってると取っ付きやすい。
■藤井智弘 氏
■自己紹介（P.2/24）
・日本ヒューレット・パッカード所属。日本だと運用系のツールが高い評価を戴いている。
・「ディシプリンド・アジャイル・デリバリー」という書籍を最近訳した。
 | ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド (Object Oriented SELECTION) (2013/06/22) Scott W. Ambler、Mark Lines 他 商品詳細を見る |
■"エンタープライズ","DevOps"？（P.3/24）
・以下2種類がある。
(1) サンドボックスタイプ
・「新規ビジネスをやります」ということでプロトタイプ作ってやるタイプ。
・リーンスタートアップに近いやり方。
(2) BETAタイプ
・べたなエンタープライズ。
■"BETA"なエンタープライズの特質（P.4/24）
①しがらみがある。
・他システムとの連携のしがらみだったり。
・運用一筋何十年という人もいたり。
②スキル
・エンタープライズだとテスターさえプログラム書けないのが当たり前だったり。
③別にそんなに頻繁に"リリース"しない
・なので、エンタープライズにDevOpsっていらないんじゃ？
■ギャップは、"BETA"なればこそ（P.5/24）
・体制が確立されているべたなエンタープライズこそ、DevOpsのギャップが出る。
・図で、左のDevOpsは「開発側視点」、右のOpsDevは「運用側視点」。
・DevOpsは頻繁リリースが注目されるが、そこがビジネスの中心でない。
・P.6のプロセス成熟度の話はあとでブログに載せる。
■リリース・プロセスの効率化（P.8/24～）
・今まではビルドとかリグレッションテストとか、図の枠１つ１つを自動化していた。
・DevOpsではそれじゃダメ。
・ステージがある。
・リリースプロセスに対して、リリースのステージングで適切なタイミングで適切なテストを行う。
・ステージが違うということはインフラが違う。
・テストを自動化しても、インフラのミスマッチで無駄なテストが出る。
・我々がやりたいのは、リリースプロセスの効率化ではなく成熟化。
・アジャイルだろうがなんだろうが関係ない。
■サンドボックスから開放せよ（P.22/24）
・DevOpsをサンドボックスから開放して、エンタープライズに持って行きたい。
★感想：
基調講演だけでお腹いっぱいになるくらい充実した講演でした。
特に響いたのが「Infrastructures as Code」という用語ですね。
この日ここで初めて聞きましたが「インフラをコード/ソフトウェアとして捉える」という概念は斬新ですね。
Gradleとか、まさしくこれが当てはまる気がします。
明日以降、基調講演以外もブログ書く予定です。
どうせ会社に聴講報告せにゃならんし、自分の復習にもなるし。
講演者のみなさま、ありがとうございました。
