DevOps 原則に基づく XNUMX つの変革の原型

「devops をどのように実装するか」という問題は何年も前から存在していますが、適切な資料はあまりありません。 場合によっては、どうやっても自分の時間を切り売りする必要がある、あまり賢くないコンサルタントの広告の餌食になることがあります。 これらは、巨大企業の船が宇宙の広がりをどのように耕すかについての、漠然とした非常に一般的な言葉である場合もあります。 これは私たちにとって何を意味するのでしょうか?という疑問が生じます。 著者の皆さん、自分のアイデアをリストに明確にまとめていただけますか?

これらすべては、企業文化の変革の結果についての実際の実践と理解があまり蓄積されていないという事実に起因しています。 文化の変化は長期的なものであり、その結果はXNUMX週間やXNUMXか月で現れるものではありません。 長年にわたって企業がどのように構築され、失敗してきたのかを見てきた十分な年齢の人材が必要です。

ジョン・ウィリス - DevOps の父の 2018 人。 ジョンには、膨大な数の企業と仕事をしてきた数十年の経験があります。 最近、ジョンは、それぞれの作業を行うときに発生する特定のパターンに気づき始めました。 これらの原型を使用して、John は企業を DevOps 変革の真の道に導きます。 これらのアーキタイプについて詳しくは、DevOops XNUMX カンファレンスでの彼のレポートの翻訳をご覧ください。

スピーカーについて:

IT 管理に 35 年以上携わり、Canonical で OpenCloud の前身となる会社の創設に参加し、10 社のスタートアップに参加し、そのうち XNUMX 社は Dell と Docker に売却されました。 現在、SJ Technologies の DevOps およびデジタル プラクティス担当副社長を務めています。

次はジョンの視点からの物語です。

私の名前はジョン ウィリスです。私を見つけるのに最も簡単な場所は Twitter です。 @ボチャガルペ。 Gmail と GitHub で同じエイリアスを持っています。 あ このリンク 私のレポートやプレゼンテーションのビデオ録画を見つけることができます。

私はさまざまな大企業の CIO と多くの会合を持っています。 彼らは、DevOps が何なのか理解できないとよく不満を言いますが、DevOps について説明しようとする人は皆、別のことについて話しています。 もう XNUMX つのよくある苦情は、ディレクターが説明どおりにすべてを実行しているように見えるにもかかわらず、DevOps が機能しないというものです。 私たちは創業XNUMX年を超える大企業について話しています。 彼らと話し合った結果、多くの問題に対して最適なのはハイテクではなく、比較的ローテクな解決策であるという結論に達しました。 何週間もの間、私はさまざまな部門の人々と話をしました。 投稿の最初の写真にあるのは私の最後のプロジェクトで、これが XNUMX 日間の作業後の部屋の様子です。

DevOpsとは何ですか?

確かに、10人に質問すれば10通りの答えが返ってくるでしょう。 しかし、興味深いのは、これらの 10 個の答えはすべて正しいということです。 ここに間違った答えはありません。 私は約 XNUMX 年間、DevOps に深く関わっており、最初の DevOpsDay には最初のアメリカ人でした。 私が DevOps に携わる他の誰よりも賢いとは言いませんが、DevOps にこれほど多くの労力を費やした人はほとんどいません。 私は、DevOps は人的資本とテクノロジーが結合することで実現すると信じています。 私たちはあらゆる種類の文化についてよく話しますが、人間的な側面については忘れがちです。

現在、私たちは 2000 年間にわたる学術研究、産業規模での理論の検証など、多くのデータを手に入れています。 これらの研究からわかることは、組織文化の中でいくつかの行動パターンを組み合わせると、5000 倍のスピードアップを達成できるということです。 この加速に匹敵するのは、安定性の向上です。 これは、DevOps があらゆる企業にもたらすメリットを定量的に測定したものです。 数年前、私はフォーチュン 5 企業の CEO と DevOps について話していましたが、プレゼンテーションの準備をしていたとき、自分の長年の経験を XNUMX 分で要約しなければならなかったので、とても緊張しました。

最終的に私は次のようにしました DevOpsの定義：これは、人的資本をパフォーマンスの高い組織資本に変えることを可能にする一連の実践とパターンです。 その一例は、過去 50 年または 60 年間にわたるトヨタの経営方法です。

（以下、図は参考資料としてではなく、イメージとして掲載します。新会社ごとに内容は異なります。ただし、画像は個別に拡大してご覧いただけます） このリンクで。)

そのような実践で最も成功しているものの XNUMX つは、 バリューストリームマッピング。 これについてはいくつかの良い本が書かれていますが、その中で最も成功した本はカレン・マーティンによるものです。 しかし、この XNUMX 年間で、私はこのアプローチですらハイテクすぎるという結論に達しました。 確かにメリットがたくさんあるので、私もよく使っています。 しかし、CEO がなぜ会社が新しいレールに切り替えられないのかと尋ねたとき、バリュー ストリーム マッピングについて話すのは時期尚早です。 最初に答えなければならない、もっと根本的な質問がたくさんあります。

私の同僚の多くが犯す間違いは、会社に 100 つのポイントからなるガイドを与えただけで、150 か月後に戻ってきて何が起こったかを確認することだと思います。 バリュー ストリーム マッピングのような優れたスキームにも、盲点があると言えます。 さまざまな企業の取締役と何百回も面談した後、私は問題をその構成要素に分解できる特定のパターンを開発しました。これから、これらの構成要素をそれぞれ順番に説明していきます。 技術的な解決策を適用する前に、私はこのパターンを使用します。その結果、壁はすべて図で覆われています。 最近私は投資信託に取り組んでいたのですが、最終的にそのようなスキームを XNUMX ～ XNUMX 個作成することになりました。

悪い文化は朝食に良いアプローチを食べる

主な考え方は次のとおりです。組織の文化そのものが悪ければ、リーン、アジャイル、SAFE、DevOps をどれだけ取り入れても役に立たないということです。 それは、スキューバ装備なしで深海に潜ったり、X線検査なしで手術したりするようなものです。 言い換えれば、ドラッカーとデミングの言葉を言い換えれば、悪い組織文化は、どんな良いシステムも窒息させることなく飲み込んでしまうのです。

この主な問題を解決するには、次の手順を実行する必要があります。

1. すべての作業を可視化する: すべての作業を見えるようにする必要があります。 それは必ず何らかの画面に表示されなければならないという意味ではなく、観察可能でなければならないという意味です。
2. 統合された作業管理システム: 管理システムを統合する必要があります。 「部族的」知識と組織的知識の問題では、9 件中 10 件の場合、ボトルネックは人々です。 本の中で 「フェニックスプロジェクト」 問題はブレントという一人の人物にあり、そのせいでプロジェクトが予定より XNUMX 年も遅れてしまったのです。 そして、私はどこでもこの「ブレント」に遭遇します。 これらのボトルネックを解決するために、リストにある次の XNUMX つの項目を使用します。
3. 制約理論の方法論: 制約理論。
4. コラボレーションハック: コラボレーションハック。
5. トヨタカタ（型のコーチング): トヨタ・カタについては多くは語りません。 興味があれば、私の github で プレゼンテーションがあります これらのトピックのほぼすべてについて。
6. 市場指向の組織: 市場志向の組織。
7. シフトレフト監査人: サイクルの初期段階で監査を行います。

私が組織で働き始めるのはとてもシンプルです。会社に行って従業員と話すのです。 ご覧のとおり、高度な技術はありません。 必要なのは何かを書き込むものだけです。 私は複数のチームを 7 つの部屋に集め、10 つの原型の観点から彼らが教えてくれたことを分析します。 それから私は彼らにマーカーを渡し、これまでに声に出して言ったことをすべて黒板に書くように頼みます。 通常、この種の会議ではすべてを書き留める 40 人がいますが、その人が書き留められるのはせいぜいディスカッションの XNUMX% です。 私の方法では、この数字を約 XNUMX% まで高めることができます。

(このイラストは個別に見ることができます) リンクを参照)

私のアプローチはウィリアム・シュナイダーの研究に基づいています。 リエンジニアリングの代替手段）。 このアプローチは、あらゆる組織は XNUMX つの正方形に分割できるという考えに基づいています。 私にとってこのスキームは通常、組織を分析するときに生じる他の何百ものスキームを使って作業した結果です。 管理レベルは高いが、能力は低い組織があるとします。 これは非常に望ましくない選択肢です。誰もがラインを守っているのに、何をすべきか誰も知らない場合です。

もう少し良い選択肢は、コントロールと能力の両方を高いレベルで備えた選択肢です。 そのような企業が利益を上げているのであれば、おそらく DevOps は必要ありません。 管理レベルは高く、能力や協力性は低いが、同時に高い文化 (教養) レベルを持つ会社と働くのが最も興味深いです。 これは、その会社にはそこで働きたいと思う人がたくさんいて、離職率が低いことを意味します。

(このイラストは個別に見ることができます) リンクを参照)

厳格なガイドラインを持った方法は、結局は真実に到達するのを妨げているように私には思えます。 特にバリュー ストリーム マッピングでは、情報をどのように構造化するかに関する多くのルールがあります。 私が今話している仕事の初期段階では、誰もこれらのルールを必要としません。 手にマーカーを持った人がボード上で会社の実際の状況を説明する場合、これが状況を理解するための最良の方法です。 そういった情報は取締役には届きません。 この時点で、その人の話を遮って、ある種の矢印を間違って引いたと言うのは愚かです。 この段階では、単純なルールを使用することをお勧めします。たとえば、複数レベルの抽象化は、複数色のマーカーを使用するだけで作成できます。

繰り返しますが、高度な技術はありません。 黒いマーカーは、すべてがどのように機能するかについての客観的な現実を示しています。 人々は現状の気に入らない点を赤いマーカーでマークします。 私ではなく彼らがこれを書くことが重要です。 会議の後に CIO に会いに行くとき、私は修正する必要がある 10 個の項目のリストを提供しません。 私は、社内の人々の発言と既存の実証済みのパターンとの関連性を見つけるよう努めています。 最後に、青色のマーカーが問題に対する考えられる解決策を示唆します。

(このイラストは個別に見ることができます) リンクを参照)

このアプローチの例を上に示します。 今年の初め、私はある銀行で働いていました。 そこのセキュリティ担当者は、設計や要件のレビューに来るべきではないと確信していました。

(このイラストは個別に見ることができます) リンクを参照)

そして、他の部門の人々に話を聞いたところ、約 8 年前、ソフトウェア開発者が作業の遅れを理由にセキュリティ担当者を解雇したことが判明しました。 そして、それは当然のこととして禁止されました。 実際には禁止はありませんでしたが。

私たちの会議は非常に混乱した形で進みました。約 XNUMX 時間、XNUMX つの異なるチームはコードとアセンブリの間で何が起こっているのか私に説明できませんでした。 そしてこれが最も簡単なことのように思えます。 ほとんどの DevOps コンサルタントは、これについては誰もがすでに知っていると事前に想定しています。

すると、XNUMX 時間沈黙していた IT ガバナンス責任者が、私たちが本題に入ると突然生き返り、非常に長い間私たちを魅了しました。 最後に、私は彼にその会議についてどう思うか尋ねました、そして、私は彼の答えを決して忘れません。 彼は、「私たちの銀行にはソフトウェアを提供する方法が XNUMX つしかないと思っていましたが、今では XNUMX つあることが分かりました。XNUMX つについては知りませんでした。」と述べました。

(このイラストは個別に見ることができます) リンクを参照)

この銀行での最後の会議は投資ソフトウェア チームとの会議でした。 彼女と一緒に、マーカーで紙に図を書く方がボードに書くよりも、さらにはスマートボードに書くよりも優れていることがわかりました。

ご覧の写真は、会議XNUMX日目のホテルの会議室の様子です。 そして、これらのスキームを使用してパターン、つまり原型を検索しました。

そこで私は作業員に質問をし、その答えを黒、赤、青の XNUMX 色のマーカーで書き留めます。 私は彼らの答えを元型について分析します。 それでは、すべてのアーキタイプを順番に説明しましょう。

1. すべての作業を可視化: 作業を可視化します。

私が働いているほとんどの会社では、未知の仕事の割合が非常に高いです。 たとえば、これは、ある従業員が別の従業員のところに来て、単に何かをしてほしいと頼むときです。 大規模な組織では、60% の計画外の作業が発生する可能性があります。 そして、作業の最大 40% はまったく文書化されていません。 もしそれがボーイングだったら、私は一生その飛行機には二度と乗らないでしょう。 作業の半分しか文書化されていない場合、この作業が正しく行われているかどうかはわかりません。 他のすべての方法は役に立たないことがわかります。何かを自動化しようとしても意味がありません。既知の 50% が作業の最も一貫性があり明確な部分である可能性があり、自動化しても大きな結果は得られず、最悪の結果が得られるからです。物事は目に見えない部分にあります。 文書が存在しない場合、あらゆる種類のハッキングや隠れた作業を見つけることは不可能であり、ボトルネック、つまりすでに話したまさに「ブレント」を見つけることも不可能です。 ドミニカ・デグランディスの素晴らしい本があります 「仕事を見える化する」。 彼女は明かす XNUMX つの異なる「タイムリーク」 (時間泥棒):

• 仕掛品（WIP）が多すぎます
• 不明な依存関係
• 計画外の作業
• 矛盾する優先順位
• 無視された仕事

これは非常に価値のある分析であり、この本は素晴らしいものですが、データの 50% しか表示されない場合、このアドバイスはすべて役に立ちません。 ドミニカが提案した方法は、90% 以上の精度が達成されれば使用可能です。 私が話しているのは、上司が部下に 15 分の仕事を与えても、それには XNUMX 日かかるという状況についてです。 しかし、上司は、この部下が他の XNUMX 人か XNUMX 人に依存していることを実際には知りません。

フェニックス プロジェクトは、90 年遅れたプロジェクトに関する素晴らしい物語です。 登場人物の一人はこのために解雇に直面し、彼は一種のソクラテスとして表現された別の登場人物と出会う。 彼は正確に何が間違っていたのかを理解するのに役立ちます。 会社にはブレントという名前のシステム管理者がいて、すべての作業はどういうわけか彼を介して行われていることがわかりました。 ある会議で、部下の一人が「なぜそれぞれの 9 分のタスクに 63 週​​間かかるのですか?」と尋ねました。 答えは、キュー理論とリトルの法則を非常に簡略化したもので、このプレゼンテーションでは、占有率 7% の場合、各時間の作業に 9 時間かかることがわかります。 各タスクは他の XNUMX 人に送信する必要があるため、その時間は XNUMX の XNUMX 倍、XNUMX 時間になります。私が言いたいのは、リトルの法則や複雑なキュー理論を使用するには、少なくともデータが必要であるということです。

したがって、可視性について話すときは、すべてが画面上にあるという意味ではなく、少なくともデータが存在するという意味です。 その場合、非常に大量の計画外の作業が、必要がないのにどういうわけかブレントに送信されていることが判明することがよくあります。 そしてブレントは素晴らしい男で、決してノーとは言わないが、自分の仕事のやり方を誰にも話さない。

作業が可視化されると、データをきちんと分類することができ (写真でドミニカが行っていることです)、XNUMX 回のリークの抽象化を適用し、自動化を適用することができます。

2. 作業管理システムの統合: タスク管理

私が話している原型は一種のピラミッドです。 最初のものが正しく行われていれば、5000 つ目はすでに一種のアドオンです。 これらの多くは新興企業には機能せず、フォーチュン 10 のような大企業では念頭に置く必要があります。私が最後に働いていた会社には 30 個の発券システムがありました。 あるチームは Remedy を使用し、別のチームは何らかの独自のシステムを作成し、XNUMX 番目のチームは Jira を使用し、一部のチームは電子メールで対応しました。 会社に XNUMX の異なるパイプラインがある場合にも同じ問題が発生しますが、そのようなケースすべてを議論する時間はありません。

私は、チケットがどのように作成されるか、次にチケットに何が起こるか、そしてチケットがどのように回避されるかについて、人々と正確に話し合います。 最も興味深いのは、ミーティングに参加する人々が非常に誠実に話していることです。 本来「大きな影響」を与えるべきチケットに「軽微な影響／なし」としている人が何人いるのかを尋ねました。 ほぼ全員がこれを行っていることが判明しました。 私は非難には関与せず、あらゆる方法で個人を特定しないように努めます。 彼らが私に何かを真剣に告白したとき、私はその人を見逃しません。 しかし、ほぼ全員がシステムをバイパスするということは、すべてのセキュリティが本質的に粉飾決算であることを意味します。 したがって、このシステムのデータから結論を引き出すことはできません。

チケットの問題を解決するには、メイン システムを XNUMX つ選択する必要があります。 Jira を使用している場合は、Jira のままにしてください。 代替手段があるなら、それが唯一のものであるようにしましょう。 肝心なのは、チケットは開発プロセスの別のステップとして見るべきだということです。 すべてのアクションにはチケットが必要であり、開発ワークフローを通過する必要があります。 チケットはチームに送信され、チームがストーリーボードに投稿し、責任を負います。

これは、インフラストラクチャや運用を含むすべての部門に当てはまります。 この場合、状況について少なくともある程度のもっともらしいアイデアを形成することが可能です。 このプロセスが確立されると、各アプリケーションの責任者を特定することが突然簡単になります。 なぜなら、現在私たちは新しいサービスの 50% ではなく 98% を受けているからです。 このコアプロセスが機能すると、システム全体の精度が向上します。

サービスパイプライン

これもまた大企業にのみ当てはまります。 新しい分野の新しい会社の場合は、腕まくりして Travis CI または CircleCI を使用してください。 フォーチュン 5000 企業に関して言えば、私が働いていた銀行で起こった好例がその例です。 Google が彼らのところに来て、古い IBM システムの図を見せられました。 Google の人たちは混乱して尋ねました - これのソース コードはどこにありますか? しかし、ソースコードはおろか、GUIすらありません。 これが大企業が対処しなければならない現実です。それは、古代のメインフレーム上にある 40 年前の銀行記録です。 私のクライアントの XNUMX 人は、Circuit Breaker パターンを備えた Kubernetes コンテナと Chaos Monkey をすべて KeyBank アプリケーションに使用しています。 ただし、これらのコンテナは最終的に COBOL アプリケーションに接続します。

Google の人たちは、私のクライアントの問題をすべて解決してくれると完全に自信を持っていましたが、その後、「IBM データパイプとは何ですか?」と質問を始めました。 彼らは、「これはコネクタです」と言われます。 それは何につながるのでしょうか？ スペリーシステムへ。 で、それは何ですか？ 等々。 一見すると、どのような種類の DevOps があるのでしょう? しかし実際にはそれは可能です。 ワークフローを配信チームに引き継ぐことができる配信システムがあります。

3. 制約の理論: 制約の理論

XNUMX 番目の原型である制度的/「部族」の知識に移りましょう。 原則として、どのような組織にも、すべてを理解し、すべてを管理する人が数人います。 彼らは組織に最も長く在籍しており、すべての回避策を知っている人たちです。

これが図上に現れたとき、私は特にそのような人々をマーカーで丸で囲みます。たとえば、あるルーがすべての会議に出席していることが判明しました。 そして、これは地元のブレントであることは明らかです。 CIO が T シャツとスニーカーを着た私とスーツを着た IBM の男性のどちらかを選ぶとき、私が選ばれたのは、他の人が話さなかったり、ディレクターが聞きたくないかもしれないことをディレクターに言えるからです。 。 私は、彼らの会社のボトルネックはフレッドという名前の人とルーという人であると伝えます。 このボトルネックを解消する必要があり、何らかの方法で彼らから知識を得る必要があります。

この種の問題を解決するには、たとえば Slack の使用を提案できます。 賢い監督なら「なぜ？」と尋ねるでしょう。 通常、このような場合、DevOps コンサルタントは次のように答えます。「誰もがそうしているからです。」 監督が本当に賢いなら、「だからどうした」と言うでしょう。 そして、これで対話は終わります。 これに対する私の答えは次のとおりです。会社にはフレッド、ルー、スージー、ジェーンという 5 つのボトルネックがあるからです。 知識を制度化するには、まず Slack を導入する必要があります。 あなたのウィキはすべて、その存在を誰も知らないため、完全にナンセンスです。 エンジニアリング チームがフロントエンドとバックエンドの開発に関与しており、質問がある場合はフロントエンド開発チームまたはインフラストラクチャ チームに連絡できることを全員が知っておく必要がある場合。 そのとき、おそらくルーかフレッドがウィキに参加する時間ができるでしょう。 そして、Slack で、たとえばステップ XNUMX が機能しない理由を誰かが尋ねると、ルーまたはフレッドが Wiki の手順を修正します。 このプロセスを確立すると、多くのことが自然にうまくいくようになります。

これが私の重要なポイントです。ハイ テクノロジーを推奨するには、まずその基盤を整える必要があります。これは、今説明したローテク ソリューションで行うことができます。 高度なテクノロジーから始めて、なぜそれが必要なのかを説明しないと、一般に、うまくいきません。 当社のクライアントの 30 つは、非常に安価でシンプルなソリューションである Azure ML を使用しています。 質問の約 XNUMX% は自己学習マシン自体によって回答されました。 そしてこれは、データサイエンス、統計、数学に関与していないオペレーターによって書かれました。 これは重要なことです。 このようなソリューションのコストは最小限です。

4. コラボレーションハック: コラボレーションハック

XNUMX 番目の原型は、孤立と闘う必要性です。 ほとんどの人はすでにこのことを知っています。孤立は敵意を生みます。 各部門が独自のフロアにあり、エレベーター以外で人々が互いに交わらない場合、部門間で敵対関係が非常に簡単に生じます。 しかし、逆に、人々が同じ部屋にいる場合、彼女はすぐに立ち去ります。 誰かが、たとえば、これこれのインターフェースは決して機能しないなどの一般的な非難を投げかけたとき、そのような非難を解体するのにこれほど簡単なことはありません。 インターフェイスを作成したプログラマーは、具体的な質問を開始するだけで済みます。たとえば、ユーザーが単にツールを間違って使用しただけであることがすぐに明らかになります。

孤立を克服する方法はたくさんあります。 以前、オーストラリアの銀行からコンサルティングを依頼されたことがありましたが、子供が XNUMX 人と妻がいるという理由で断りました。 彼らを助けるために私にできることは、グラフィカルなストーリーテリングを勧めることだけでした。 これは効果があることが証明されているものです。 もう XNUMX つの興味深い方法は、リーン コーヒー ミーティングです。 大規模な組織では、これは知識を広めるための優れたオプションです。 さらに、社内の Devopsday やハッカソンなどを実施することもできます。

5. 型の指導

冒頭で警告したように、今日はこれについては話しません。 興味があれば、見てみることができます 私のプレゼンテーションの一部.

このトピックについては、Mike Rother による優れた講演もあります。

6. マーケット指向: 市場指向の組織

ここにはさまざまな問題があります。 たとえば、「I」人、「T」人、「E」人です。 「私」とは、一つのことしかやらない人です。 通常、これらは部門が分離された組織に存在します。 「T」は、人が XNUMX つのことに優れているが、他のことにも優れていることを意味します。 「E」または「comb」は、その人が多くのスキルを持っていることを意味します。

ここではコンウェイの法則が機能します (コンウェイの法則)、最も単純化した形式では、次のように言えます: XNUMX つのチームがコンパイラーに取り組む場合、結果は XNUMX つの部分からなるコンパイラーになります。 したがって、組織内で高度な分離が行われている場合、その組織内の Kubernetes、サーキット ブレーカー、API の拡張性などの派手なものも、組織自体と同じように配置されることになります。 コンウェイによれば、すべての若いオタクを苦しめるために。

この問題の解決策は何度も説明されています。 たとえば、フェルナンド フェルナンデスによって説明された組織の原型があります。 先ほど話した、分離を伴う問題のあるアーキテクチャは、機能指向のアーキテクチャです。 XNUMX 番目のタイプは最悪のマトリックス アーキテクチャで、他の XNUMX つをごちゃ混ぜにしたものです。 XNUMX 番目はほとんどのスタートアップに見られるもので、大企業もこのタイプにマッチしようとしています。 市場志向の組織です。 ここでは、顧客のリクエストに最速で対応できるように最適化します。 これはフラット組織と呼ばれることもあります。

多くの人がこの構造をさまざまな方法で説明していますが、私はこの表現が好きです チームを構築/運営する、アマゾンではそれを呼んでいます XNUMXつのピザチーム。 この構造では、タイプ「I」の人々はすべて XNUMX つのサービスの周りにグループ化され、徐々にタイプ「T」に近づき、適切な管理が行われていれば「E」になることもあります。 ここでの最初の反論は、そのような構造には不要な要素が含まれているということです。 特別な部門のテスターを置くことができるのに、なぜ各部門にテスターが必要なのでしょうか? 私はこう答えます。この場合の追加コストは、将来的に組織全体がタイプ「E」になるための代償です。 この構造では、テスターはネットワーク、アーキテクチャ、設計などについて徐々に学習します。 その結果、組織内のすべての参加者は、組織内で起こっているすべてのことを完全に認識します。 このスキームが業界でどのように機能するかを知りたい場合は、以下をお読みください。 マイク・ローザー、トヨタ・カタ.

7. シフトレフト監査人: サイクルの早い段階で監査を行います。 安全規則の遵守を展示

これは、いわば、あなたの行動が匂いのテストに合格していないときです。 あなたの下で働いている人々は愚かではありません。 上の例のように、どこにでも軽度/無影響を設定し、これが XNUMX 年間続き、誰も何も気付かなかった場合、システムが機能しないことは誰もが完全に知っています。 または別の例として、変更諮問委員会では、毎週、たとえば水曜日に報告書を提出する必要があります。 そこで働いている人々のグループ（ちなみにあまり給料は高くありません）があり、理論的にはシステム全体がどのように機能するかを知っているはずです。 過去 XNUMX 年間で、おそらく私たちのシステムが信じられないほど複雑であることに気づいたでしょう。 そして、XNUMX 人か XNUMX 人の人が、自分たちが行っていない、何も知らない変更について決定を下さなければなりません。

もちろん、このアプローチは機能しません。 この人たちは制度を守っていないので、そういうものをなくさなければなりません。 チームが責任を負わなければならないため、決定はチーム自身が行う必要があります。 そうしないと、人生で一度もコードを書いたことのないマネージャーがプログラマーにコードを書くのにどれくらいの時間がかかるかを指示するという逆説的な状況が発生します。 私が一緒に働いていたある会社には、アーキテクチャ ボードや製品ボードなど、すべての変更をレビューする 7 つの異なるボードがありました。 強制的な待機期間さえありましたが、ある従業員は、XNUMX年間働いてきて、この義務的な期間中にこの人が行った変更を拒否した人は一人もいなかったと私に言いました。

監査人は排除されるのではなく、私たちに加わるよう招待される必要があります。 すべてのテストに合格すると、永久に不変のままとなる不変のバイナリ コンテナを作成することを伝えます。 コードとしてパイプラインがあることを伝え、それが何を意味するのか説明してください。 次のスキームを示します。すべての脆弱性テストに合格したコンテナ内の不変の読み取り専用バイナリです。 そして、パイプラインは動的に作成されるため、誰もそれに触らないだけでなく、パイプラインを作成するシステムにも触りません。 私のクライアントである Capital One は、Vault を使用してブロックチェーンのようなものを作成しています。 監査人は Chef からの「レシピ」を示す必要はありません。ブロックチェーンを示すだけで十分であり、そこから、本番環境で Jira チケットに何が起こったのか、誰がその責任者であるのかが明確になります。

による 届出は、2018 年に Sonatype によって作成され、2017 年には 87 億件の OSS ダウンロード リクエストがありました。

脆弱性によって生じる損失は法外なものです。 さらに、上に表示されている数字には機会費用が含まれていません。 DevSecOps とは簡単に言うと何ですか? すぐに言っておきますが、私はこの名前がどれほど成功したかについて話すことに興味はありません。 重要なのは、DevOps が非常に成功しているため、そのパイプラインにセキュリティを追加するように努めるべきであるということです。

このシーケンスの例:


私はどの製品も気に入っていますが、これは特定の製品を推奨するものではありません。 これらを例として挙げたのは、当初は業界の組織パラダイムに基づいていた DevOps によって、製品の作業のあらゆる段階を自動化できることを示すためです。

そして、セキュリティに対して同じアプローチをとれない理由はありません。

合計

結論として、DevSecOps に関するヒントをいくつか紹介します。 システムの作成プロセスに監査人を含め、監査人を教育するために時間を費やす必要があります。 監査人と協力する必要があります。 次に、誤検知に対して徹底的に容赦なく戦う必要があります。 最も高価な脆弱性スキャン ツールを使用したとしても、信号対雑音比がどのくらいかを把握していなければ、開発者に非常に悪い習慣を植え付けることになる可能性があります。 開発者はイベントに圧倒されてしまい、単純にイベントを削除してしまいます。 Equifax の話を聞いたなら、それが最も高い警戒レベルが無視されたそこで起こったこととほぼ同じです。 さらに、脆弱性はビジネスにどのような影響を与えるかを明確に説明する必要があります。 たとえば、これは Equifax の話と同じ脆弱性であると言えます。 セキュリティの脆弱性は、他のソフトウェアの問題と同じように扱う必要があります。つまり、DevOps プロセス全体に含める必要があります。 Jira、Kanban などを通じてそれらと連携する必要があります。 開発者は、他の誰かがこれを行うだろうと考えるべきではありません。逆に、誰もがこれを行うべきです。 最後に、人材の育成にエネルギーを費やす必要があります。

便利なリンク集

ここでは、DevOops カンファレンスの役立つ講演をいくつか紹介します。

• Sergey Berdnikov、Artyom Kalichkin - サクセス ストーリー、または「Dev+DevOps+Ops」(ビデオ, 報告書の写し)
• Baruch Sadogursky、Leonid Igolnik - スケール上の DevOps: XNUMX 幕のギリシャ悲劇 (ビデオ, 報告書の写し)
• アレクサンダー・チトフ、キリル・トルカチョフ - DevOps、エンジニア、コミュニティ
• ティモシー・リスター - 個性、コミュニティ、文化: 繁栄の重要な要素

調べる программу DevOops 2020 モスクワ ――興味深いものもたくさんありますね。

出所： habr.com