- 本文は個人の見解であり、所属する組織の公式見解ではありません。
はじめに
- DevOpsやらChatOpsやら、やたらとオペレーション（運用）が重要な位置付けとなり、継続的に且つ高速に運用改善を行うことがインターネットサービス成長の鍵とも言える状況のように思います
- そんな中でDevOpsに始まる言葉がバクッとしてイマイチ理解しづらく、チームに馴染まない状況がある
- そんな状況を少しでも改善すべく、個人的な見解でDevOps周りを整理する
DevOpsとは
- wikiを見ると
DevOps（デブオプス[1]）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する開発手法をさす。[1] また、DevOpsにビジネス部門を追加したBizDevOpsというワードも広がりつつある。ただし2013年現時点では厳密な定義は存在しておらず、抽象的な概念に留まっている。
参照）https://ja.wikipedia.org/wiki/DevOps
→まぁ抽象的な概念にを指してる様子
抽象的な概念だからイマイチ分からなくなってる
- 上記のwikiからもわかるように何をしたらDevOpsなんてものはないし、抽象的な概念って言ってるからしょうがない。けど何となくこれをしたらDevOpsじゃない？的な感覚がある気がする
- なので特にエンジニア以外の仲間には伝わりにくいのだと思われる
DevOpsを理解する為の前提となるような理解
全体としてこんな感じ
- 最近巷で言われているDevOpsを取り入れた開発のフロートはこんなイメージで大きくわけて「Business」「Ops(運用)」「Dev(開発)」を担当するメンバーが存在します。
- それぞれの役割のメンバーが相互に関わりプロダクトを作っていく。
それぞれちょっと説明すると
①ビジネス
- ビジネスの企画やアイデアを中心となって考えだす
- 主に営業的な人たちや、ディレクターと呼ばれるような人たちがこのあたりにいる
②運用、設計
- ①で考案された機能やアイデアをシステムの観点から具体的に設計や調査
- その他に既存システムの運用や監視等の業務を担当
- 開発された社内システムのオペレーション操作をする人たちもこのへんにいる
- 運用のエンジニア+システムオペレーターといった人たち
③開発
- ②で流れてきたものを実際に開発をする。性能テストや受け入れテスト等はOps側と協力して行う
- その他にインフラ関連の運用等も担当
- ソフトエンジニア、インフラエンジニアがこのあたりにいる
注意
- と何となくの登場する役職と役割を記したけど、それぞれ共同所有というような意識を持つ事は前提だし、飛び越えて業務をしていかないと良いプロダクトには結びつかない
外枠のループ
- idea→計画→設計→development→learnといったループはそれぞれの役割が中心的に行っていき、このループを高速回転させることで良いプロダクトを生み出していく
- lean的な要素も踏まえ、アジャイル、スクラム的なエッセンスを踏まえこのループを回す事が重要
上記のような理解を踏まえてDevOpsとは
- 組織が大きくなればなるほど、横のつながり＝協力が無くなり、大企業病へと発展しあっという間に衰退する。
- そのような状況を防ぎ、上記の主な登場人物をいかに密接に結びつけて且つ、良いプロダクトを作るループをいかに高速回転させるか、、、それを実現するのがDevOpsなんじゃなかろうか
- コストという考え方はもう無く、サービス開発においてもはや必要経費DevOps
- スピード(サービス開発のスピード/レスポンススピード)のためにどうテクノロジを最適化させていくかが、DevOps
ではもうちょい具体的にDevOpsを因数分解していくと
下記のようかな
DevOps
├─ツール
│ ├─共有
│ │ ├─slackのような優れたコミュニケーションツール
│ │ └─kibanaのような誰でも分かりやすく可視化されたツールの共有
│ ├─測定
│ │ ├─テストカバレッジの指標
│ │ └─監視系の数値メトリックス
│ └─自動化
│ ├─デプロイ等の自動化
│ ├─ユニットテストの自動化
│ ├─E2Eテストの自動化
│ └─サーバ構築の自動化
│
└─文化形成
└─関わる全ての人が専門性を持ち寄り、ツールを通じて協力するという「カルチャー」が必要
共有
- 基本的にすべての情報は社内公開され誰もで自ら取得できる状態にしてにして無駄な情報共有MTGを減らす
- 非同期コミュニケーションを最大限に活用
- 同期コミュニケーションが不必要と言っているわけではないよ
測定
- パフォーマンス数値からサーバの数値までメトリックすを取得して、いつどのような状態になり、何がボトルネックになったかを瞬時に把握する
自動化
- どんな簡単な作業であれ、人の手を介するのであれば、人手は必要になります。
- 人の稼働時間は決まってるため、増えてくると解決には単純に人の手を増やすか、または自動化という選択肢が残ります。
- 人はそこまで増やすことはできないので自動化を取り組みます
- 自動化によって、瞬時に必要な集計データは揃い、判断に必要なデータは揃い、ジャッジをして次の動作へうつれます
文化
- ツールを導入が進んでもそれを使いこなせないと全く意味がありません。
- そういったツールの理解を会社全体として推し進め、文化として育てることが必要
まとめ的なもの
- ざっくり言うとDevOpsとは関係する役職を結び助けるツールまたは文化のようなもの。
- これをやることがDevOpsだ的な考えでいるとハマる
- とは言え、定量的な目標があった方が人間は努力しやすいのである程度決めることは良いと思う
- 1日N回リリースできる状況が出来てることを目指す
- 新規サーバを数十分内に構築してサービスインさせること...とかね
- 自動化は一つのキーワードで考えるがあまり陥りやすい罠として運用コストをN%減らすにはどうすべきか的な考えはあまり良くない（全てではないけどね）。自動化などの技術を使ってどうプロダクトを伸ばすかという思考のが健全
- プロダクトの成長を加速させることがDevOpsであり、コスト削減ではない
- 成長、サービスのスケールに必要投資
おまけ
- ここ最近SRE(Site Reliability Engineering)という言葉が出始めている
- 参照：http://www.google.com/about/careers/lifeatgoogle/site-reliability-engineers-the-worlds-most-intense-pit-crew.html
- 日本語にするのはナンセンスだけど、信頼性エンジニア的な感じ
- 一つのサービスでも細分化させ、高度化される中でトラブルシュートやパフォーマンス改善を行うにあたり、ハードとソフト両面の理解が必要になり、横断的な対応が必要になります。こういった部分を担っていくエンジニアとしてSREというのが確立されつつあるっぽいね
- 各種クラウドサービス的なものが増えて横断しやすくなったのも関係するかも