Chef流 DevOps 功夫

Chef Style DevOps Kung fu by Chef Software, Inc. is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. A full list of incorporated sources is included.

Navigate using the left and right arrows.

Gōngfu (功夫)

功 (gōng) は、「仕事」、「達成」、「利点」などを意味する。
夫 (fū) は、「人」を意味する文字として使われる。

長年の練習により達成されたスキルの卓越

ソース

武術

基本
型
応用

Devops 功夫

実務哲学の深い理解
個人に固有の幅広い経験
基本と型を認識する
自分の状況に実用的に応用

There is a deep well of practical philosophy
There is a broad base of experience, unique to each individual
We are recognizably similar
There is a way to teach people how to do it
It starts with the basics, and everyone must master them
It moves to Forms - predetermined behaviors that can be combined into continuous sets of actions
It ends in Application - actually doing your Kung fu in the field, using what you have learned
TMTOWTDI is true and honest and important
However - if you don't know how to do it, you could probably skip the 15+ year journey of difficulty
And practice the basics, learn the forms, and apply them in your life

勝つために議論をするのではない。

進歩するために議論するのだ。

DevOpsは、私たちがビジネスをやってきたやり方の再発明である

誰がやるの？?

みんな全員

やり方は異なる。原則は同じ。
ジェネラリストではない。我々はうまく繋がったスペシャリストだ

Chef流DevOps功夫

この後援をサポートしている人、Chef流DevOps功夫の実践者じゃないよ

Mark Burgess	Johnny Cash	John Allspaw	Sammy Hagar
Nathan Haneysmith	Ronnie James Dio	Tom Thomas	Jesse Leach
Christopher Brown	Ben Rockwood	Jesse Robbins	Jez Humble
Barry Crist	Thich Naht Hanh	Mitch Hill	Larry Wall
Paul Edelhertz	Lao Tzu	Soo Choi	Jennifer Dumas
Alex Ethier	Yukihiro Matsumoto	Jeff Hackert	Theo Schlossnagle

リストは順不同で完全でもない。部屋から僕は逃げ出した。

基本文書

Githubにある: http://github.com/chef/devops-kungfu
PRで参加
一緒に、原則、型、応用を作っている
フォークして、名前を消して、内容を足して、自分の道場を始めよう

This talk is my foundational document of that Kung fu
Once you have watched it, you can join my school
We can develop the basics, our forms, and help on application
Talib Kweli explained to me that artists amplify the movement they see in the world
Marvin Gaye didn't write What's Goin On and
then
the movement happened
The movement happened, and Marvin had to respond to, and amplify it, with his art
That is my intent here - I will use my platform to raise up the voices of those who are doing the work
And we can then leverage it as a platform to help each other
And to further our aims of having our workplace be a better place

DevOpsの要素

原則	(どこでも通じる)
型	(共有される)
応用	(それぞれ固有)

The principles we aspire to (How you recognize DevOps when you see it)
Wushu calls this the 'basics', but it involves a lot of pushups, and there isn't a lot of pushups in devops
This includes a definition of DevOps
The forms we use - the actual things we practice, that try and re-enforce and bolster our principles
The application - the use of those forms in our actual situation
These three things are the evolutionary arc of your practice - in the beginning, you learn from others
As you grow, you will use the forms others have used to learn about the deeper meaning and philosophy
The more you apply them in practice, the less reliant on the forms you will be - it all just becomes the natural flow
Leading you, and anyone else, to be where those of us with already strong Kung Fu are - uniquely suited to our task
(It's not about whether you are good at it - it's about the soul of our kung fu)

原則

共有されている信念。全てのDevOpsのスタイルの基礎

DevOps

文化的かつ専門的な運動で、ハイベロシティ組織を作り、動かす方法に集中する。実務家たちの経験から生まれた。

文化的かつ専門的

文化的ヒップホップ、ヘビメタもしくはオタクのように
専門的 MC、リードギター、アニメーターのように

DevOps: 文化的かつ専門的な運動で、ハイベロシティ組織を作り、動かす方法に集中する。実務家たちの経験から生まれた。

作る方法、動かす方法に集中する

我々がものを作り、
それから時間をかけて動かす詳細の指針を示す

DevOps: 文化的かつ専門的な運動で、ハイベロシティ組織を作り、動かす方法に集中する。実務家たちの経験から生まれた。

ハイベロシティ組織

我々はハイベロシティ組織を作る経験しかない
ロウベロシティ組織に同じ原則を適用しても、安定性を損ねるだけだ

DevOps: 文化的かつ専門的な運動で、ハイベロシティ組織を作り、動かす方法に集中する。実務家たちの経験から生まれた。

実務家たちの経験から生まれた

我々のほとんどはウェブイノベーターだった
DevOpsの最初の探検家たち

DevOps: 文化的かつ専門的な運動で、ハイベロシティ組織を作り、動かす方法に集中する。実務家たちの経験から生まれた。

自分たちと顧客の双方に、安全、満足、知識、自由をもたらすための設計

安全

人間の安全
情報の安全
意図せぬ結果を恐れずに実行できる個人の能力

安全には範囲がある – システムによって、安全のしきい値は異なる。

満足

すでに持っているものに満足していること。

幸福はゴールではない。よく生きた人生の副産物だ。
- エレノア・ルーズベルト

知識

知識にアクセスできることは、社会的進歩の先行指標である。

必要な知識を最小にすることがゴールではない。必要な時に豊かな知識にアクセスできるようにすることがゴールだ。

邪魔されたり抵抗されたりすることなく、考えたいことを考え、言いたいことを言い、やりたいことをやる能力もしくは権利
– The Internet

我々は、自分たちと周りの人々が、邪魔されずに、考え、言い、行動できるように力を与えるべきだ。

人々

製品

会社

我々はリーンだ

価値を生まない活動はやめる (ムダ)
プッシュよりプル
改善 (継続的改善)
改革 (破壊的な変革)
小さいバッチ + 小さい実験

ユビキタスワークフロー自動化

多様性

型

多くのスタイルで共有される。重点はスタイルによって異なる

みんなに見せる
まず一つだけやってみる
助けようとする人々も一緒に
製品も一緒に
助けようとする人が見る変化も一緒に

最も変革を起こしつつ生き残っている会社は、ソフトウェア駆動の組織を速く、効率的、イノベーティブにするために、Chefを使う。

あなたの環境で良い成果をもたらすもの
書き出して、みんなから見えるように
DevOpsの原則を含める
自分の産業、課題に固有なことと混ぜる

私たちはユーザーのためにソフトウェアを作る。ユーザーのために正しいことをやる。
(The Right Hard Thing)

権限移譲されたチーム

行動する許可を与えられている
良い判断を下せるコンテキストにある
目的を大事にするリーダーがいて
信念を共有している

多様な繋がりを築く

自分の専門外の人たちとランチに行こう、会議をしよう
やりたいことを尋ねて、彼らの課題と視点を理解しよう
法務、財務、営業、マーケティング、ビジネス開発、ソフトウェア開発、システム管理、セキュリティ専門家、製品

Take people to lunch, or have meetings, outside your specialty
Ask them what they do, and try and understand
You need to talk to:
Legal (Ask them what the role of a lawyer is, and how you can help make any interactions you have smooth)
Finance (Ask them what the role of a finance is, what key metrics they watch, and how you can help)
Sales (Ask them what their quota is, what do they struggle with at customers, and how can you help them make their number)
Marketing (Ask them what message is resonating, why, and how they see the market evolving)
Business Development (Ask them what partners are moving the needle, how they think about those arrangements, and whats on the horizon)
Software Development (Ask them what they are building, and why it matters, and what they are excited about in the future)
Systems Administrators (Ask them about availability, what do they think is the biggest limit to your organizational efficiency)
Security Professionals (Ask them how they evaluate your business and technology in terms of risk, how you can help)
Product (Ask them what they think the gaps in your product are, and to talk about the last 5 customers they've met)

重要な判断についてコンセンサスを築く

繋がりを使ってステークホルダーに計画を回覧しよう
計画への批判やフィードバックを取り込もう
グループに提示しよう
コンセンサスを求めよう

強いバリュープロポジション

ビタミンではなく鎮痛剤
人々が♡
要求ではなく必要を (ある顧客が要求する機能、全ての顧客が必要とする機能)

Make products that have strong value propositions

Product/Pain Relievers/Gain Creators
Map to Customer Jobs, Customer Pains, and Customer Gains
Pain Killers not vitamins
Make something people LOVE
Needs not wants (customer wants a feature, customer(s) need features)
How to identify the opportunities
Call out customer pain through engagement
Interview customers to learn about their problems
Solve the pain you experience yourself
Write down your ideas for products What is it? (product) Who is it for? (target customers) What problem does it solves and why does it matter? (problem & pain) How does it work? (pain relievers & gain creators) What is unique about it? (uniqueness) What is the value proposition? (value) How do we make money? (cost & revenue)

ロードマップを描く

ビジョンから始める
顧客のフィードバックに寄り添って
イノベーションと顧客ニーズのバランス
テーマごとにグループに分け, それぞれの成果を示す
フィーチャーとして蒸留し、顧客からの有効性確認を得よう

テーマは維持すべき
成果は維持できるかも
フィーチャーはきっと変わる

いつでも魅力的品質を

反復的にフィーチャーを作る

	1	2	3
モナリザを描く漸進的
田園の女性反復的

Jeff Pattonによる素晴らしいアナロジー

リスクを管理する

小さなバッチ、直近の仮説
有効性の確認は顧客から
直近のベロシティを導入して、長期リスクの低減を得る

スケーリングについては心配するな

必要になるまで

思ったよりずっと後だ

理論についての議論は、実行で解決する

毎週
見せたいものがある人なら誰でも
全員招待する
録画して、社内で見れるように

仕事にあった言語とツールを選ぶ

みんなたくさんの言語を使える
新しい言語やツールを覚えるのは、この業界における最高の喜びのひとつだ
小さいバッチ + 反復型開発がリスクからの守り

バグデータベースを持て

バグのトリアージと優先度付け
顧客に親切に

継続的統合

常にブランチをmasterに統合する
ブランチは短命に、反復ブランチ
赤くなったらビルドを直せ

四つの瞳ルール

テスト書け

単体テスト (単一の機能)
結合テスト (複数のクラスやユニット)
機能テスト (ユーザー志向、ハイレベル、フルスタック)
スモークテスト (システムが「動いている」か素早く調べる)

変更をやる方法は1つだけ

組織内を変更が流れるやり方は固定されている
原則を再強化しフローを助けるように設計されている
実行レベルで柔軟性を持たせる

コードは同じワークフローを流れる

アプリケーションはコード
インフラストラクチャもコード

可用性に集中せよ

可用性 = 動いている時間/(動いている時間+止まっている時間)
平均分析時間と平均修理時間を減らす努力に集中する
失敗は避けられない; 発見し対応する方法が問題だ

メトリクスを収集せよ

OS、ネットワーク、アプリケーケーション、プロセス
高分解能であることが重要
可能な限りシステムの数は少なく

キャパシティを計画せよ

重要なメトリクスを特定する
それをグラフにする
限界値を決める
傾向線を示す
タイムホライゾンを拡大する

対応可能なものだけ警告せよ

適切な人間だけの注意を引く
可能な限り警告の数を少なく
行動を起こせる人に導く
システム停止警告から始める

事故対応を訓練せよ

状況判断が一番重要なステップだ

事故対応を訓練せよ

初期対応者が、デフォルトで事故対応指揮官となる
次にやることを決める
リソースを調整する
状況を知らせる
組織での地位は関係ない
事故対応指揮官は、必ず一人だけ。

事故後は検死を行う

場を設定する: 学ぶためにいる。誰かを責めるためではない。
事故を説明する
タイムラインを確立する
事故を招いた要素を特定する
顧客への影響を説明する
軽減策を説明する
対応プロセスの改善策を説明する

スケール可能なシステム設計を用いる

自律アクター, 自身に責任を持つ
自身のゴールへ進む
他のアクターに明確な約束をする
約束の品質評価をアクターに行わせる

あなたのコードについて
あなたの地位について
あなたの知識について

シンプルさ

拡張性

再利用

一人一人に固有

安全性のテクニック

原則を思い出せ
型を練習せよ
自身の洞察を使え

Stage 1-課題の選択

8週間で有意な繰り返し可能なくらい十分に小さく
垂直に切って小さくする、水平にではなく

Stage 2-目的、信念、チーム

目的を書き出す
信念を書き出す
チームが行動できるよう権限移譲する
コンテキストで利用できるように

Stage 3 - プロダクト開発

バリュープロポジションを記述する
ロードマップ (テーマ, 成果, フィーチャー)を描く
魅力的品質を含める
シンプルさ、拡張性、再利用

Stage 4 - フィーチャーの反復

フィーチャーの反復
小さいバッチ、顧客からの有効性検証によりリスクを管理する
仕事にあった言語とツールを選ぶ
スケーリングは無視
理論についての議論になったら、実行に再フォーカス
毎週デモ

Stage 4 - フィーチャーの反復

ソースコード管理を使う
バグデータベースを持つ
変更ワークフローはひとつ
四つの瞳

Stage 4 - フィーチャーの反復

継続的統合
継続的デリバリ
テストは一つづつ。(単体、結合、機能、スモーク)
スケール可能なシステム設計を使う

Stage 5 - 運用

可用性にフォーカス
メトリクスを収集
キャパシティを計画
実行可能なものにだけ警告を
事故対応を実行
検死を実施

ステージ 6 - 出荷

最後のデモ
ふりかえり

Chef流 DevOps 功夫

Githubにある: http://github.com/chef/devops-kungfu
PRで参加
一緒に、原則、型、応用を作っている
フォークして、名前を消して、内容を足して、自分の道場を始めよう

自分の道を見出せ

DevOpsは本物だ
どこでも通じる原則で、私はわかった。
共有された型で、私は練習する
私の日々の仕事に、応用する
私のやり方は、私固有のものだ。あなたのも。