Chef流 DevOps 功夫

Adam Jacob / CTO of Chef / @adamhjk

Chef Style DevOps Kung Fuの日本語翻訳です。

Creative Commons License
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.

Kung Fu Santa

Gōngfu (功夫)

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

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

ソース

武術

  1. 基本
  2. 応用
The Thing as Boxer

Devops 功夫

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

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

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

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

誰がやるの??

みんな全員

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

Chef流DevOps功夫

Chef Style
この後援をサポートしている人、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で参加
  • 一緒に、原則、型、応用を作っている
  • フォークして、名前を消して、内容を足して、自分の道場を始めよう
Creative Commons License

DevOpsの要素

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

原則

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

DevOps

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

文化的かつ専門的

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

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

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

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

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

ハイベロシティ組織

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

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

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

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

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

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

安全

  • 人間の安全
  • 情報の安全
  • 意図せぬ結果を恐れずに実行できる個人の能力
安全には範囲がある – システムによって、安全のしきい値は異なる。

満足

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

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

知識

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

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

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

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

人々

製品

会社

我々はリーンだ

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

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

多様性

多くのスタイルで共有される。重点はスタイルによって異なる
  • みんなに見せる
  • まず一つだけやってみる
  • 助けようとする人々も一緒に
  • 製品も一緒に
  • 助けようとする人が見る変化も一緒に
最も変革を起こしつつ生き残っている会社は、ソフトウェア駆動の組織を速く、効率的、イノベーティブにするために、Chefを使う。
  • あなたの環境で良い成果をもたらすもの
  • 書き出して、みんなから見えるように
  • DevOpsの原則を含める
  • 自分の産業、課題に固有なことと混ぜる
私たちはユーザーのためにソフトウェアを作る。ユーザーのために正しいことをやる。
(The Right Hard Thing)

権限移譲されたチーム

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

多様な繋がりを築く

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

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

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

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

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

ロードマップを描く

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

いつでも魅力的品質を

delighters
反復的にフィーチャーを作る
1 2 3
モナリザを描く
漸進的
Mona lisa head Mona lisa head/arm Mona lisa whole
田園の女性
反復的
Mona lisa sketch Mona lisa wash Mona lisa whole

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

リスクを管理する

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

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

必要になるまで

思ったよりずっと後だ

理論についての議論は、実行で解決する
  • 毎週
  • 見せたいものがある人なら誰でも
  • 全員招待する
  • 録画して、社内で見れるように

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

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

バグデータベースを持て

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

継続的統合

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

四つの瞳ルール

テスト書け

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

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

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

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

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

可用性に集中せよ

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

メトリクスを収集せよ

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

キャパシティを計画せよ

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

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

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

事故対応を訓練せよ

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

事故対応を訓練せよ

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

事故後は検死を行う

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

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

  • 自律アクター, 自身に責任を持つ
  • 自身のゴールへ進む
  • 他のアクターに明確な約束をする
  • 約束の品質評価をアクターに行わせる
  • あなたのコードについて
  • あなたの 地位について
  • あなたの知識について

シンプルさ


拡張性


再利用

 
一人一人に固有

安全性のテクニック

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

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で参加
  • 一緒に、原則、型、応用を作っている
  • フォークして、名前を消して、内容を足して、自分の道場を始めよう
Creative Commons License

自分の道を見出せ

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