ジェフ・スミスとのスマッシングポッドキャストエピソード42：DevOpsとは何ですか？

このエピソードでは、DevOpsについて話します。 それは何ですか、そしてそれはあなたのウェブ開発の弓に追加するための文字列ですか？ ドリュー・マクレランが専門家のジェフ・スミスと話をして調べます。

メモを表示

• Twitterのジェフ
• ジェフの本OperationsAnti-Patterns、DevOps Solutions
• 達成可能なDevOps

毎週の更新

• MatthewTalebiによって書かれたデザイナーと開発者の間のギャップを埋める
• GauravKhannaによって作成されたTypeScriptを使用して柔軟なコンポーネントを構築するための便利なReactAPI
• CosimaMielkeによって作成された一般的なUIチャレンジのためのスマートCSSソリューション
• ナタリヤサンビルによって書かれたUX/UIデザイナーを評価するためのヒントとコツ
• アリジットモンダルによって書かれたNext.jsを利用したEコマースWebサイトでCLSの問題を解決する

トランスクリプト

Drew McLellan：彼はDevOpsの実践者であり、旅のどこにいても、達成可能なレベルのDevOps実装に焦点を当てています。 彼はデジタル広告プラットフォームCentroの制作オペレーションのディレクターであり、パブリックスピーカーでもあり、DevOpsの知識を世界中の聴衆と共有しています。 彼は、ほとんどの開発者が作業するような不完全な環境でDevOps手法を実装する方法を示す本、Operations Anti-Patterns、DevOps Solutions for Manning Publishingの著者です。したがって、彼はDevOpsの専門家ですが、Georgeを知っていましたかクルーニーは彼を世代の最高の紙飛行機メーカーと見なしていますか？ 私のスマッシングの友達、ジェフ・スミスを歓迎してください。 こんにちはジェフ。 元気ですか？

ジェフ・スミス：私は壊している、ドリュー、お元気ですか？

ドリュー：元気です。 ありがとう。 よかったね。 そこで、今日は、主要な主要分野の1つであるDevOpsのテーマについてお話ししたいと思います。 私たちのリスナーの多くはWebやアプリの開発に携わっていますが、運用面で何が起こっているのかについてはあまり詳しくないかもしれません。 大企業で働く可能性のある私たちには、業務を行っている同僚のチーム全体がいることを私は知っています。 彼らが何をしていても、彼らがうまくやってくれていることに感謝しています。 しかし、DevOpsがますます言及されていると聞いており、開発者として私たちが本当に理解しなければならないことの1つのように感じます。 では、Jeff、DevOpsとは何ですか？

ジェフ：つまり、20人にDevOpsとは何かを尋ねると、20の異なる答えが得られる可能性があります。 それで、私はあなたにそれについての私の見解を与えます、大丈夫です、そしてあなたが会議にいて、あなたがこれに言及するならば、あなたは誰かとの最初の戦いに入ることができることを知っています。 しかし、私にとって、DevOpsは実際にはその間の関係についてであり、開発と運用に焦点を当てていますが、実際にはチーム間の関係と、作業の構造化、さらに重要なことに、目標とインセンティブを構造化して、それらが共通の目標に向かって取り組んでいるように調整されています。 そして、DevOpsのコアとなるアイデアや概念の多くは、devとopsが常に敵対的であり、この絶え間ない対立があった旧世界から来ています。 そして、あなたがそれについて考えるとき、それはそれらの2つのチームがインセンティブを与えられる方法のためです。 1つのチームは、変更をプッシュするように奨励されています。 別のチームは、安定性を維持するように奨励されています。つまり、変更が少なくなります。

ジェフ：そうするとき、あなたはこの固有の対立を生み出し、そこからすべてがこぼれます。 つまり、DevOpsは、共通の戦略に向けて取り組むようにチームと目標を調整するだけでなく、双方からのプラクティスを採用することで、開発者はopsについてより深く理解し、opsはdevについてより深く理解し、獲得して共有する方法として機能します。お互いに共感し、相手がどこから来ているのかを理解できるようにします。

ジェフ：しかし、それから私たちの仕事を強化するためにも。 繰り返しになりますが、私があなたの視点を理解し、それを私の仕事で考慮に入れれば、それは私たち一人一人にとってはるかに有益になるでしょう。 また、自動化の観点から、運用担当者が開発者から学ぶことができることはたくさんあります。また、簡単に再現できるように、どのようにアプローチするかについても学ぶことができます。 つまり、このブレンドとスキルです。 そして今あなたが見ているのは、これがさまざまなグループの組み合わせに適用されるということです。そのため、DevSecOps、DevSecFinOps、DevSecFinHROpsなどの音が聞こえます。 それは成長し続け、成長し続けます。 ですから、それは本当に私たちが組織全体に打ち出すことができる教訓です。

ドリュー：つまり、開発者として理解している概念のいくつかを取り入れて、アイデアを組織にさらに広めると同時に、運用から何ができるかを学び、全員を前進させようとしています。

ジェフ：もちろんです。 opsのもう1つの側面は、イントロで少し触れましたが、専用のopsチームなどを備えたこれらの大規模な組織のためだけのものだと思いますが、考慮すべきことの1つは、組織内でopsが発生していることです。サイズに関係なく。 それはあなたがそれをしているのか、それとも別のチームがそれをしているのかという問題ですが、どういうわけかあなたはコードをデプロイしています。 どういうわけか、どこかでサーバーを実行しています。 したがって、運用は、規模に関係なく、組織のどこかに存在します。 問題は、誰がそれをしているのかということです。 また、それが1人の場合、または1つのグループの場合は、opsが行うことの種類を理解する必要があるため、DevOpsはさらに顕著になる可能性があります。

Drew：プロの開発者として、DevOpsとは何か、実装することの意味をよく理解することは、私たちにとってどれほど重要だと思いますか？

ジェフ：特にDevOpsジャーニーのこのフェーズでは、これは非常に重要だと思います。 そして、私が重要だと思う理由は、相手が何をしているのかを理解するとき、私たちは常により効率的だと思うからです。 ただし、もう1つは、設計の開発およびテクノロジの実装時に、運用上の懸念を考慮に入れることができるようにすることです。 ですから、私のキャリアで学んだことの1つは、開発者は宇宙の達人だと思っていて、コンピューターに関係するすべてのことを理解していても、実際にはそうではないということです。 理解の観点から、運用にアウトソーシングしていることがたくさんあり、その結果、特定の設計の選択や実装の選択が本番環境の展開に最適でない場合があります。

ジェフ：彼らは開発やテストなどでうまくいくかもしれませんが、本番環境に入ると、それは少し異なるボールゲームになります。 したがって、彼らはその専門知識のセット全体を所有する必要があるとは言えませんが、少なくとも彼らが知らないことを知るのに十分な知識を持っている必要があります。 つまり、開発が選択を行うという一般的なパターンであるため、彼らはいつ運用を早期に開始するかを知っています。 彼らはそれが選択であるとさえ認識していないので、私は選択をすることさえ言いませんが、運用のための次善の決定につながる何かが起こり、開発は完全に気づいていませんでした。 ですから、運用についてもう少し知識を持っているだけで、たとえそれで十分だとしても、先に進む前に、運用を取り入れて彼らの視点を得る必要があるかもしれません。 それはあなたがリリースしているどんな製品にも関係しているので、明らかにそれは多くの時間とエネルギーと安定性を節約することができます。

ドリュー：私たちがデザインと開発の間で持っているように、開発と運用の間の関係について話している方法と非常に多くの類似点があります。そこでは、デザイナーがインターフェースの動作と外観に取り組んでいて、よく理解しています。それが実際に開発の役割にどのように組み込まれるかを理解し、開発者に相談してもらうことで、明確なコミュニケーションとお互いの行動を理解するだけで、ソリューション全体を本当に改善できます。 同じ原則がDevOpsで実行されたように見えますが、これは本当に、本当に聞いて良かったです。

Drew： DevOpsについて聞いたことを考えると、Kubernetes、Docker、Jenkins、CircleCIなどの用語が聞こえます。 Kubernetesについては何年も聞いています。 それが何であるかはまだわかりませんが、あなたが言っていることから、DevOpsは単なるツールではないようです…ここではツールについて話しているだけではありませんか？ しかし、ワークフローでのコミュニケーションのプロセスと方法については、そうですか？

ジェフ：もちろんです。 したがって、過去20年間の私の信条は、常に人々がツールを処理することでした。 あなたは人々にビジョンに賛同してもらう。 そこから、そのビジョンを達成するためにプロセスがどのように見えるかを定義します。 そして、プロセスが何であれ、モデル化するツールを導入します。 そのため、私は常にツールをDevOpsの会話の最後に置きます。主な理由は、その賛同がなければ、それは問題ではないからです。 史上最高の継続的デプロイパイプラインを思いつくことができましたが、すべての変更を本番環境に直接出荷するというアイデアに人々が同意しなければ、それは問題ではありませんか？ ツールは何が良いですか？ したがって、これらのツールは、私たちが定義したいくつかの一般的な目標を達成するための標準化された方法であるという理由だけで、間違いなく会話の一部です。

ジェフ：しかし、定義されている目標が組織にとって意味のあるものであることを確認する必要があります。 たぶん、継続的デプロイはあなたにとって意味がありません。 たぶん、あなたはそれが出てきた瞬間にすべての変更を出荷したくないでしょう。 そして、あなたがそれをしたくない理由はたくさんの会社や組織と理由があります。 したがって、継続的デプロイのパイプラインのようなものは意味がないかもしれません。 したがって、ツールは重要ですが、組織に価値をもたらすものに焦点を当て、それを実現するために必要なツールをモデル化して実装することがより重要です。

ジェフ：しかし、オンラインに接続して、誰もが何をしているのかを調べて、DevOpsを実行する場合は、DockerとKubernetesに切り替える必要があります。これがツールチェーンだからです。 いいえ、そうではありません。 あなたはそれらのものを必要としないかもしれません。 誰もがGoogleではありません。 誰もがNetflixであるわけではありません。 NetflixとGoogleからの投稿を読むのをやめます。 それらを読むのをやめてください。 それは人々をすべて興奮させ、彼らは好きなので、これが私たちがやらなければならないことです。 そしてそれは、まあ、彼らはあなたが持っている問題とは非常に異なる問題を解決しているようなものです。

ドリュー：つまり、私が新しいプロジェクトを始めているとしたら、おそらく私はスタートアップ企業であり、サービス製品としてのソフトウェアを作成しています。 私には3人の開発者がいて、空のGitリポジトリがあり、IPOの夢があります。 この製品を構築するためのDevOpsアプローチに全面的に取り組むために、人とプロセスの観点から配置する必要のあるビルディングブロックの名前は何ですか？また、どこから始めればよいですか？

ジェフ：あなたの特定の例では、私が最初に始める場所は、可能な限りそのほとんどをパントし、Herokuなどの何かをその効果のために使用することです。 AWSやDockerのすべてに興奮しているので、実際には、成功する製品を構築するだけでは非常に困難です。 あなたがそのDevOps部分に焦点を合わせているという考えは、それが実際に問題点になるまで、可能な限り多くのものをアウトソーシングすると言うでしょう。 しかし、あなたが大丈夫だと言っているその時点にいるなら、私たちはこのようなものを家に持ち込む準備ができており、それを次のレベルに引き上げる準備ができています。 最初に始めるのは、どこに問題があるのか​​ということです。 あなたに問題を引き起こしているものは何ですか？

ジェフ：つまり、自動テストと同じくらい簡単な人もいます。 ねえ、誰かがコミットするたびにテストを実行する必要があるという考え。これは、すでに作成した単体テストに引っかかったものを出荷することがあるためです。 したがって、継続的インテグレーションから始めるかもしれません。 展開が完了するまでに数時間かかり、非常に手動である場合は、そこに焦点を当てて、これをワンボタンクリックで実行できるようにするために必要な自動化について説明します。 しかし、私は将軍を処方するのは嫌いです。あなたの特定の状況とあなたの特定の問題点が異なるだろうという理由だけで、これはあなたが始めるところです。 そして、それが問題点であるなら、それはあなたに向かって叫んでいるはずです。 それは絶対にあなたに向かって叫んでいるはずです。

ジェフ：それは、誰かがあなたの組織に何が悪いのかと言うことの1つでなければなりませんか？ そして、それは、ああ、私はそれが何であるかを正確に知っているようなものでなければなりません。 したがって、その観点からアプローチすると、DevOpsツールボックスで解凍して作業を開始するために必要なものに関して、次のステップがかなり明確になると思います。 そして、これらの最小限の増分変更が継続的に行われるようになり、新しい機能を取得すると、標準以下のものに対する欲求が非常に小さくなることに気付きます。 だから、あなたは、そうそう、展開には3時間かかり、それは大丈夫です。 あなたはそれにいくらかの努力をしました、そしてあなたが知っている次のことは、3週間で、あなたはまるで、男、私は展開がまだ30分かかっているとは信じられません。 これを30分からどうやって下げるのですか？ あなたの食欲は改善のために飽くなきになります。 だから、物事はそこからこぼれ出るだけです。

Drew：私はあなたの最近の本を読んでいて、それはあなたがDevOpsの4つの柱と呼んでいるものを強調しています。 そして、前述のように、それらのどれもツールではありませんが、必要に応じて、DevOpsの焦点となるこれらの4つの主要な領域があります。 最初のものが文化であることに気づきました。まず、ツールについてもっと話してくれることを期待していたので、その理由がわかりましたが、文化に関しては、奇妙に思えます。最初に持っているもの。 技術的なアプローチの基盤があります。 文化は、組織内でDevOpsの実装を成功させる方法にどのように影響しますか？

ドリュー： …組織内でDevOpsの実装をどれだけ成功させることができるか。

ジェフ：文化は、あなたがそれについて考えるとき、本当にすべての基盤です。 そして、それは重要です。なぜなら、文化、そして私たちは本の中でこれをもう少し深く掘り下げますが、文化は実際に組織内の規範の舞台を設定します。 右。 あなたはおそらく、自動テストなしでPRを提出した場合、それは大したことではない会社にいました。 人々はそれを受け入れて先に進みます。

ジェフ：しかし、それが根本的な罪である他の組織があります。 右。 あなたがそれをしたとしたら、それは「おお、あなたは正気じゃないの？ 何してるの？ ここにはテストケースはありません。」 右。 それは文化です。 それは、「これは私たちがしていることではない」というような規範を強制している文化です。

ジェフ：自動化されたテストケースを作成するというドキュメントは誰でも作成できますが、組織の文化が人々の間でそのメカニズムを強化しています。 これは、文化が非常に重要である理由のほんの一例です。 文化が恐怖の文化、報復の文化である組織がある場合。 それはあなたが間違いを犯した場合のようなものです、そうです、それは犠牲です。 右。 それは反逆に等しいです。 右。

ジェフ：あなたはその組織で、危険を冒したり失敗したりする可能性のあるものに不利な行動を起こします。 そして、それはテーブルに多くの機会を残すことになります。 一方、失敗から学ぶことを受け入れる文化を作る場合は、人々が実験できる心理的安全性のこの考えを受け入れます。 そして、彼らが間違っている場合、彼らは安全に失敗する方法を理解し、再試行することができます。 あなたは実験の文化を手に入れます。 あなたは人々が新しいアイデアにオープンである組織を手に入れます。

ジェフ：私たちは皆、こういう会社に行ったことがあると思います。 そして、誰もそれを変えません。」 右。 世界は絶えず変化しているので、あなたはそれを望んでいません。 文化が存在するために組織内の行動の多くが存在するため、文化を最前線に置くのはそのためです。

ジェフ：そして重要なのは、文化的俳優は善悪を問わない可能性があるということです。 右。 皮肉なことに、この本でもこれについて話しますが、組織文化を変えるのにあなたが思っているほど多くの人を必要としないということです。 右。 なぜなら、ほとんどの人は、批判者、支持者、そしてあらゆる種類の変化に関してはフェンスシッターがいるからです。 そして、ほとんどの人はフェンスシッターです。 右。 スケールを実際に傾けるのに必要なのはほんの一握りのサポーターだけです。 しかし、同じ意味で、スケールを傾けるのに実際にはほんの一握りの批判者しか必要としません。

ジェフ：それは、文化をより良い方向に変えるのにそれほど時間はかからないようなものです。 そして、そのエネルギーを投入すれば、シニアリーダーでなくても、チームの文化に影響を与えることができ、それが部門の文化に影響を与え、組織の文化に影響を与えることになります。

ジェフ：これらのアイデアと行動を大声で支持し、「これらは私たちがこれから得ている利点です」と言うだけで、個々の貢献者としてこれらの文化的変化を起こすことができます。 だからこそ、文化は最前線にある必要があると思います。なぜなら、すべての人にこのアイデアを受け入れてもらう必要があり、組織として、それは価値があり、それをサポートすることを理解する必要があるからです。

ドリュー：うん。 それは生き方でなければならない、と私は思います。

ジェフ：その通りです。

ドリュー：うん。 私は自動化の分野に本当に興味があります。なぜなら、私のキャリアを通して、効果がなかった自動化が実施されているのを見たことがないからです。 右。 つまり、奇妙なことは別として、何かが自動化されてうまくいかない場合があります。 一般に、時間をかけて手動で行っていることを自動化すると、常に時間とヘッドスペースが節約され、肩から離れるだけです。

Drew： DevOpsアプローチを採用する際に、ワークフロー内で自動化するためにどのようなことを検討しますか？ そして、手動で物事を完了することで、それからどのような利益が期待できますか？

ジェフ：自動化に関して言えば、自動化によって生活が改善されていない時期はめったにありません。 右。 人々が遭遇する摩擦は、その自動化を構築する時間を見つけることです。 右。 そして通常、私の現在の仕事では、それが実際にリクエストのポイントです。 右。 ある時点で、「これを手動で行うのをやめ、自動化する」と言わなければならないからです。

ジェフ：そして、あなたが「あなたは何を知っていますか？ これには2週間かかります。 通常は数時間で元に戻りますが、これは自動化されたリクエストであるため、2週間かかるでしょう。」 自動化するものを特定するという点で。 Centralでは、基本的に、4週間にわたって届いたさまざまなタイプのリクエストをすべてサンプリングするプロセスを使用しています。 そして、私はそれらを計画された仕事、計画外の仕事、付加価値のある仕事、労苦の仕事として分類します。 苦労はあまり役に立たない仕事ですが、何らかの理由で、私の組織はそれをしなければなりません。

ジェフ：そして、次のようなものを特定します。「さて、これを自動化した場合に取り除くことができる、ぶら下がっている果物は何ですか？ これを単純化するために何ができるでしょうか？」 そして、いくつかの基準はプロセスのリスクでした。 右。 自動データベースフェイルオーバーは、それほど頻繁に行わないため、少し怖いです。 そしてインフラストラクチャが変化します。 右。 「私たちはどれくらいの頻度でこのことをしているのですか？」と言います。 年に1回行う場合は、価値がほとんどないため、自動化する価値がない可能性があります。 しかし、それが月に2、3回得られるもののひとつであるなら、それを見てみましょう。 わかった。

ジェフ：さて、これをスピードアップするために私たちにできることは何ですか？ そして、自動化について話すとき、私たちはすぐに「ボタンをクリックするだけで、これは魔法のように行われる」ということに飛びつきました。 右。 しかし、気が遠くなると感じた場合、自動化で実行できるさまざまな手順があります。 右。 たとえば、通常実行する10の異なるCLIコマンドで10のステップがあるとします。 自動化の最初のステップは、そのコマンドを実行するか、少なくともそのコマンドを表示するのと同じくらい簡単です。 右。 言ってやるがいい。「ねえ、これが私が実行しようとしていることです。 大丈夫だと思いますか？」 "はい。" "わかった。 これが私が得た結果です。 先に進んでも大丈夫ですか？」 "はい。" "わかった。 これが私が得た結果です。」 右。

ジェフ：そうすれば、まだ少しコントロールできます。 あなたは快適に感じます。 そして、20回の実行後、あなたはちょうどヒットしていることに気づきます、はい、はい、はい、はい、はい、はい。 あなたは言います｢大丈夫ですこれらすべてをつなぎ合わせて、すべてを1つにしましょう。」 それはあなたがの深い端に飛び込んで、それをクリックして、すぐにそれを忘れなければならないようなものではありません。 快適になるまでこれに足を踏み入れることができます。

ジェフ：これらは、自動化の取り組みの一環として行ったタイプのことです。これの所要時間を短縮し、取り組みのレベルを下げるにはどうすればよいでしょうか。 初日は100％ではないかもしれませんが、目標は常に100％に到達することです。 まず、快適に感じる部分を自動化する小さなチャンクから始めます。 はい。 私たちはこれがうまくいくと確信しています。 この部分は少し厄介なので、先に進む前に人間による検証を行うだけかもしれません。

ジェフ：自動化について話しているという観点から見たもう1つのことですが、特定のプロセスにどのような価値を追加しているのでしょうか。 そして、これは特に運用にとって顕著です。 多くの場合、opsはプロセスの仲介者として機能します。 そして、彼らの関与は、アクセスに関するものにすぎません。 右。 それは、opsがアクセスできる唯一の人であるため、opsがそれを行わなければならないようなものです。

ジェフ：まあ、それは、人々がそれを行うことができるように、どのようにそのアクセスをアウトソーシングするのですか？ 現実はそうなので、開発者が本番環境にアクセスできることを心配しているわけではありません。 右。 開発者が自由に本番環境にアクセスできるのではないかと心配しています。 そして、それは本当に安全なことです。 右。 ツールボックスに鋭利なナイフしかない場合は、誰に渡すかについて非常に注意する必要があります。 しかし、ツールボックスをスプーンとハンマーで混ぜ合わせて、人々が仕事に適したツールを選択できるようにすれば、それを貸し出すのははるかに簡単です。

ジェフ：たとえば、なんらかの理由で、本番環境でアドホックなRubyスクリプトを実行する必要があるプロセスがありました。 右。 データをクリーンアップする必要があり、いくつかの悪いレコードを修正する必要があります。 そして、それは常に私のチームを通してもたらされるでしょう。 そして、それは、私がこのチケットを承認できないので、これに何の価値も追加していないようなものです。 右。 何も思いつきません。 あなたはソフトウェアを書いたのですが、私があなたの肩に座って「まあ、それは安全だと思います」と言っていくのは何がいいのでしょうか。 右。 入力するように指示されたとおりに入力しているだけなので、入力に値を追加しませんでした。 右。

ジェフ：そして最悪の場合、そして最後に、あなたがチケットを提出しているので、私は本当にあなたにとっての障害にすぎません。そしてあなたは私が昼食から戻るのを待っています。 昼食から戻ってきましたが、他にも取り組むべきことがあります。 「これを自動化して、開発者の手に渡らせると同時に、監査に関するこれらの懸念に対処するにはどうすればよいでしょうか」と述べました。

ジェフ：それをJIRAワークフローに入れました。そこでは、JIRAチケットで指定されたコマンドの実行を自動化するボットがありました。 そして、JIRAチケットで、数人の上級エンジニアの1人からの承認が必要であることを指定できます。 右。

ジェフ：あるエンジニアが別のエンジニアの仕事を承認しているのは、彼らが文脈を持っているからです。 右。 彼らは手術を待つために座っている必要はありません。 JIRAで定義された明確なワークフローがあり、誰かが要求したときに誰かが承認したときに文書化されているため、監査部分に回答があります。 そして、そのコマンドをプルし、ターミナルでそのコマンドを逐語的に実行する自動化があります。 右。

ジェフ：私がタイプミスすることを心配する必要はありません。 私が間違ったチケットを手に入れることを心配する必要はありません。 そのため、これらのチケットの所要時間は10倍になりました。 右。 開発者のブロックは解除されます。 私のチームはこれを行うことに縛られていません。 そして、実際に必要なのは、自動化を実際に開発するための1週間または2週間の投資と、それにアクセスするために必要な許可だけでした。

ジェフ：今は完全に削除されています。 そして、開発は実際にその機能の一部を組織の下位部分にアウトソーシングすることができます。 彼らはそれをカスタマーケアにプッシュしました。 これは、カスタマーケアが、このレコードを更新する必要があることを知っているときのようです。開発は必要ありません。 この機能について承認された標準スクリプトを送信できます。 また、開発とまったく同じワークフローで実行できます。 それは本当にすべての周りに恩恵です。

ジェフ：そして、それは私たちが組織全体で仕事をどんどん低くすることを可能にします。 私たちがそうするにつれて、私がこれを実行する空想的で高価な開発者を持つことができたので、仕事はますます安くなるからです。 右。 または、顧客と直接連携しているカスタマーケア担当者に、問題を修正する顧客と電話をしているときに自分で実行してもらうこともできます。

ジェフ：自動化は、どの組織にとっても重要だと思います。 そして最後に、専門知識をエクスポートすることもできます。 右。 さて、コマンドラインで一連のコマンドを実行する必要がある場合、これを行う方法を知っているのは私だけかもしれません。 しかし、これを自動化すれば、誰にでもそれを与えることができます。 そして、人々は最終結果が何であるかを知っていますが、すべての中間ステップを知る必要はありません。 私はそれを組織に押し出し、私の専門知識を取り入れて、それを輸出可能なものに体系化することによって、私の価値を10倍に増やしました。

ドリュー：あなたは頻繁に発生するタスクの自動化について話しました。 非常にまれにしか発生しないタスクを自動化して、開発者がどのように機能するかを理解するのにかなり長い時間がかかるという議論はありますか？ 誰もが忘れているからです。 お久しぶりですね。 1年が経ちましたが、これまで誰もやったことがないかもしれません。 そのようなことを自動化することについての議論もありますか？

ジェフ：それは難しいバランスを取る行為です。 右。 そして、私はいつもそれをケースバイケースでとると言います。 そして、私がそれを言う理由は、DevOpsのマントラの1つは、何か苦痛なことがあれば、それをより頻繁に行うことです。 右。 あなたがそれを頻繁に行うほど、それはより多くの筋肉の記憶になり、あなたはそれらのねじれを解決して解決することができます。

ジェフ：非常にまれなタスクの自動化で見られる問題は、その自動化の実行の間に環境の状況が変化する傾向があることです。 右。 最終的に発生するのは、コードが環境について特定の仮定を行い、それらの仮定が無効になったことです。 したがって、自動化はとにかく壊れてしまいます。

ドリュー：そして、2つの問題があります。

ジェフ：そうですね。 右。 丁度。 丁度。 そして、あなたは「私はそれを間違ってタイプしましたか？ それともこれですか？ いいえ、これは実際には壊れています。」 それで-

ジェフ：タイプが間違っているか、これはノーです。これは実際には壊れています。 したがって、まれなタスクの自動化に関しては、ケースバイケースで実際にそれを実行して、これが機能しない場合のリスクを理解します。 私たちがそれを間違えた場合、私たちは悪い状態にありますか、それとも私たちがこのタスクを完了していないというだけですか？ したがって、これが正常に失敗し、悪影響がないことを確認できる場合は、自動化に挑戦する価値があります。 少なくとも、何が起こっているのかを理解するためのフレームワークがあるからです。少なくとも、誰かがコードを読んで理解できるようになるからです。これが私たちがやっていたことです。 そして、なぜこれが機能しなくなったのかはわかりませんが、少なくともこれが書かれた設計時から何が起こるのかははっきりと理解しています。

ジェフ：しかし、失敗がデータの変更などにつながる可能性がある状況にある場合、私は通常、注意を怠って手動で保管します。自動化スクリプトがある場合、合流点のドキュメントを見つけた場合のみです。それは3歳で、このスクリプトを実行すると言っています。私はそのスクリプトに100％の自信を持っている傾向があり、それを実行します。 右。 4年前に文書化された一連の手動の手順である場合、私は次のようになりますが、ここでいくつかの検証を行う必要があります。 右？ これを少し進めて、数人の人と話をしましょう。 そして時々、私たちがプロセスを設計するとき、その思考プロセスを強制することは価値がありますよね？ そして、あなたは人間の構成要素とそれらがどのように振る舞うのかについて考えなければなりません。 そして、私が今これを行うべきかどうかを人々に考えさせるために、プロセスをもう少し面倒にする価値がある場合がありますか？

ドリュー：システムを監視し、物事を測定することで、何を自動化する必要があるかを特定する他の方法はありますか？ つまり、私はDevOpsについて考えており、ダッシュボードはその1つである素晴らしいグラフだと考えています。 そして、これらのダッシュボードには、見た目が美しいだけでなく、もっとたくさんのことがあると確信していますが、見栄えの良いダッシュボードがあることは常に素晴らしいことです。 そのような決定を下すのを助けるために、システムが何をしているのかを測定する方法はありますか？

ジェフ：もちろんです。 そして、そのような種類のカムのメトリクス部分へのセグエは、システムが効率的に動作していることを知るためにシステムで追跡しているものは何ですか？ また、メトリックの一般的な落とし穴の1つは、成功を検証するのではなく、エラーを探すことです。 そして、それらは2つの非常に異なる慣行ですよね？ したがって、何かがシステムを流れて、必ずしもエラーになるとは限りませんが、プロセス全体を本来の方法で通過するとは限りません。 したがって、メッセージキューにメッセージをドロップすると、「そしてこのメ​​ッセージは取得されて処理されました」という対応するメトリックが存在するはずです。 そうでない場合は、すぐに不均衡になり、システムが正常に機能しなくなります。 これらの悪い状態に陥ったときに自動化する必要があるさまざまなことを理解する方法として、メトリックを使用できると思います。

ジェフ：そうですか？ 多くの場合、それは物事をきれいにするために取られる必要がある非常に単純なステップですよね？ しばらくの間操作を行ってきた人にとっては、ディスクスペースアラートです。誰もがそれを知っています。 ああ、私たちはディスクでいっぱいです。 ああ、月末を忘れて請求が実行され、請求は常にログをいっぱいにします。 そして、VARログはすべてのディスクスペースを消費しているため、ログローテーションを実行する必要があります。 右？ それがあなたの好みの一種であるならば、あなたはそのために朝の3時に起こされるかもしれません。 しかし、それが動作であることがある程度わかっている場合、メトリックはその手がかりを与えることができるはずです。 そして、ログローテーションコマンドを簡単に自動化できますよね？ ああ、このしきい値に達しました。logrotateコマンドを実行してください。 アラートがクリアされるかどうかを見てみましょう。 もしそうなら、人生を続けてください。 そうでない場合は、誰かを起こしてくれるかもしれませんね。

ジェフ：インフラストラクチャの自動化でも、これはさらに多く見られます。「ねえ、1秒あたりのリクエスト数は理論上の最大値に達しています。 たぶん、クラスターをスケーリングする必要があります。 ロードバランサープールに3つまたは4つのノードを追加する必要があるかもしれません。」 そして、必ずしも誰かが介入する必要なしにそれを行うことができます。 これらのメトリクスを確認してアクションを実行し、特定のしきい値を下回ったらそのインフラストラクチャを契約することができますが、それらのメトリクスを取得し、それを実行できるようにモニタリング環境にフックを設定する必要があります。 そこで、会話のメトリクス部分全体が登場します。

ジェフ：さらに、その情報を他の人と共有できるのも良いことです。データがあれば、共有された現実の中で物事について話し始めることができるからです。忙しいというのは一般的な用語ですが、1秒あたり5,200件のリクエストはかなりの量です。私たち全員が推論できるより具体的なもの。 そして、容量などについて話し合うときは、これらの手の波状の用語を使用することがよくあると思います。代わりに、ダッシュボードを見て、非常に具体的な値を指定し、すべての人がそれらのダッシュボードにアクセスできるようにすることができます。それらは、何らかの理由で私たちだけがアクセスできるいくつかのops壁の後ろに隠されていません。

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. 右。 So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” 右。

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. それは公正な評価ですか？

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. 右。 And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. 右。 And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. 右。 So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. 右。 I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. 右？ So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. 右。 They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. 右。 So you could be doing any manner of testing in there that is extremely complicated. 右。 It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. 右。 So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. 右。 Let me get Drew on the phone and see what's going on.” 右。 And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” 右。 So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. 右。 And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. 私の言っていることが分かるよね？ So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. Awesome.” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

ジェフ：私は彼らにそれを書きたかったのです。主に個人の貢献者と中間管理職は、「この種の段階的な変更を行うためにCTOである必要はなく、これを持っている必要はありません。 DevOpsのメリットの一部を獲得できるようにするための卸売革命。」 ですから、「ねえ、これはバラバラにできます。 これは自分で行うことができます。 そして、DevOpsをツールやKubernetesとして考えているため、DevOpsに関連しているとは思わないかもしれないこれらすべてのものがあります。」 すべての組織ではありません…州政府のように、このニューヨーク州に参加した場合、Kubernetesを一晩で実装するだけではありません。 右？ ただし、チームが互いに話し合う方法、チームが連携する方法、互いの問題を理解する方法、および自動化によってこれらの問題に対処する方法を実装できます。 それらはあなたの影響範囲内にあり、あなたの日常生活を改善することができるものです。

ジェフ：それは本当にそれらの人々への手紙でしたが、そこには十分なデータがあり、DevOps組織にいる人々が「ねえ、これはまだ私たちにとって有用です。 」 そして、多くの人は、この本を読むことで、DevOps組織に所属しておらず、役職が変わっただけだとすぐにわかると思います。 そして、それはかなり起こります。 つまり、「ねえ、私たちは現在DevOpsエンジニアですが、この本で説明されているような種類のプラクティスは行っていません。どうすればそこにたどり着くことができますか？」

Drew：それで、あなたの本はそれらの1つであるように思えますが、DevOpsを使い始めようとしている人々が頼ることができる他のリソースはありますか？ このことを学ぶのに良い場所はありますか？

ジェフ：うん。 エミリー・フリーマンのDevOpsForDummiesは始めるのに最適な場所だと思います。 それは、コアコンセプトとアイデアのいくつかをレイアウトすること、そしてそれが私たちが何を目指しているかを分類するという素晴らしい仕事を本当にします。 ですから、それは、土地を手に入れるためだけに、始めるのに良い場所でしょう。 フェニックスプロジェクトは明らかにジーンキムによるもう一つの素晴らしい情報源だと思います。 そして、それは素晴らしいことです。そのようなものは、DevOps環境にないことが引き起こす可能性のあるタイプの問題の準備を整えます。 そして、あらゆるタイプの組織で何度も見られるこれらのパターンや個性を強調するという素晴らしい仕事をしています。 それらを強調するのは素晴らしい仕事だと思います。 そして、その本を読んだら、ページで「はい、はい。 これ。 これ。" だから、それは別の素晴らしい場所です。

ジェフ：そしてそこから、DevOpsハンドブックのいずれかに飛び込みます。 私はこれを言うために自分自身を蹴るつもりです、しかしグーグルSREハンドブックは見るべきもう一つの素晴らしい場所でした。 あなたはGoogleではないことを理解しているので、すべてを実装する必要があるとは思わないでください。しかし、彼らのアイデアや戦略の多くはどの組織にとっても健全であり、何かを取り入れることができる素晴らしい場所だと思います。 「さて、私たちは、運用環境をもう少し効率的にするつもりです」と言います。 そして、それは、これらの問題のいくつかを解決するための多くの種類のプログラム的アプローチに焦点を当てているため、opsの役割を果たしている開発者にとって特に顕著になると思います。

Drew：それで、私はDevOpsについてすべてを学んでいます。 ジェフ、最近何を学んでいますか？

ジェフ： Kubernetes、男。 うん。 Kubernetesは、私たちにとって本当の種類の読書と知識の源です。 そのため、開発者にさらに力を与える手段として、現在Centroでそれを実装しようとしています。 私たちは、私たちがいる場所からさらに一歩進んで物事を進めたいと思っています。 多くの自動化が実施されていますが、現在、新しいサービスのオンボーディングに関しては、サービスの性質にもよりますが、私のチームはまだかなり深く関わっています。 そして、私たちはその仕事に従事したくありません。 開発者は、コンセプトからコード、デプロイメントに至るまでアイデアを取り入れ、運用の専門知識がシステム内で体系化されている場合にそれを実行できるようにしたいと考えています。 したがって、システム内を移動すると、システムがガイドします。 したがって、Kubernetesはそれを行うのに役立つツールだと思います。

ジェフ：それは非常に複雑です。 そして、それは一種のかみ傷に大きな部分です。 では、展開がどのように見えるかを理解するのでしょうか？ Kubernetes内でこれらの演算子をどのように活用しますか？ この新しい世界でCICDはどのように見えますか？ たくさんの本を読んでいますが、この分野では常に学んでいますよね？ どれだけ長くそこにいたか、どれだけ長くやってきたかは関係ありません。あなたはこの分野のどこかで馬鹿です。 だから、それはあなたが一種の適応するものです

Drew：ええと、私が言っているように、何年も経っても、スタックのどこにあるのかはある程度理解できますが、Kubernetesが何をしているのかはまだわかりません。

ジェフ：私は時々似ていると感じます。 少しでもやっているような気がしますよね？ 21世紀のDNSです。

ドリュー：リスナーの皆さんがジェフからもっと聞きたい場合は、ツイッターで彼を見つけることができます。彼は暗くてオタクで、彼の本と過去のプレゼンテーションやブログ投稿へのリンクを彼のサイトattainabledevops.comで見つけることができます。 本日はご参加いただきありがとうございます、ジェフ。 別れの言葉はありましたか？

ジェフ：ただ学び続けて、ただそこに出て、学び続けて、仲間と話してください。 話して、話して、話して。 一緒に仕事をしている人と話すことができるほど、理解が深まり、共感が生まれます。特に組織内に嫌いな人がいる場合は、必ず最初に話してください。