「フェニックスプロジェクト-IT運用と保守の伝説的な物語」は、かなり魔法のような本です。ストーリーテリング手法を使用して、ITチーム（開発、テスト、運用、保守）の開発効率が低く、システム配信が遅いことを示しています。 3段階の作業方法を実践することで、チームはシステムの提供を加速し、開発効率を向上させることができるため、チームはDevOpsの道に着手することができます。さらに、この本の称賛に値する部分は、製造のワークフローとの類推によって、技術チームの作業プロセスに隠された問題を直感的に発見できることです。
ここで開発者に、本を読むときは仏教徒でなければならないことを思い出させる必要があります。なぜなら、この物語は運用と保守の観点から開発されており、呪いの開発のプロットがいくつかあるからです。特定のDevOpsツールを探している場合は、それを読まないことをお勧めします。特定のツールの紹介はありませんが、DevOpsの利点と実践を説明する最も簡単な方法です。
最初にコンセプトについてお話ししましょう。
- バリューストリーム：顧客のニーズに基づいて組織が実行する一連の整然とした配信アクティビティ。または、顧客が製品やサービスに従事するための一連の活動を設計、作成、提供するために、情報フローとマテリアルフローの二重の価値が含まれています。
- 技術的価値の流れ：ビジネスアイデアを顧客への価値主導の技術主導のサービスに変換するために必要なプロセス。プロセスの入力が要件です。開発部門は、開発を完了し、全体的なテストを実施し、本番環境に展開して正常に実行し、顧客にサービスを提供して価値を生み出します。
- リードタイム：需要確認（需要の開発と受領）からタイミングを開始し、作業が完了したときに終了します
- 処理時間：実際の作業開始から終了まで
- 待機時間：需要確認（需要の開拓・受入）の開始から実際の作業開始まで
- 進行中の作業/半製品：バリューストリームで完全に完了していない作業、およびキューで作業します。部分的に完了した作業は徐々に期限切れになり、最終的には時間の経過とともに価値が失われます。
- 制限ポイント：バリューストリームのボトルネック、つまりバリューストリーム全体の流量の上限ポイント。
最初のステップ：流れの原理
[外部リンク画像の転送に失敗しました。元のサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-QGhU9U9x-1581262477847）（https://www.howardliu.cn/images/ devops / 3-ways-first）-way.png）]
最初のステップのフロー原理は、技術的価値のフローチャネルを開き、開発から運用、保守までの作業の左から右への迅速なフローを実現することです。技術的価値の流れの流量を加速することにより、顧客のニーズを満たすためのリードタイムを短縮し、作業の品質と出力を改善し、企業がより強い競争力を持つことを可能にします。関連するプラクティスには、継続的な構築、統合、テスト、および展開、オンデマンドでの環境のセットアップ、進行中の製品の数の制限、および変更を安全に実装できるシステムと組織の構築が含まれます。
作業内容の視覚化を継続的に強化し、バッチサイズと待機間隔を短縮し、欠陥が下流に渡されるのを防ぐための組み込み品質、
作品を見えるようにする
製造業では、原材料や半製品の蓄積や受注残が直感的にわかり、閉塞が発生する場所が限界です。しかし、技術的価値の流れには多くの問題が隠されており、ブロッキングポイントと制約ポイントを明確に確認する方法はありません。同時に、情報が表示されないか、相互情報量が完全でないため、問題が次のリンクに渡され、オンラインの場合にのみ問題が発生するか、まったく配信されない可能性があります。これには、作業が流れている場所、キューに入れられている場所、停滞している場所を特定するために、作業を可能な限り視覚化する必要があります。
通常、かんばん管理（日本語のかんばん）またはスプリント計画ボードをツールとして使用できます。
視覚的な管理には注意を払うべき場所があります。ローカルな目標ではなく、全体的な目標に焦点を合わせます。全体的な目標は、システムの品質を向上させ、開発の効率を向上させることです。ローカルの目標は、開発の完了率、テストの欠陥の数、およびシステムの使いやすさです。地域の目標が重要ではないというわけではありません。これらの地域の目標は他の方法で最適化する必要があります。全体的な効率を改善する必要があります。詳細に入ると、大山を見失い、把握する方法がありません。全体的な状況。これは、JeanKingが「部分的な最適化によって全体的なパフォーマンスが低下することは許可されていません」と述べたものです。
進行中の作業の数を制限する
作業が視覚化された後、品質の高い障害を見つけ始めることができます。
最初のステップは、並列タスクを制限することです。どうして？並列タスクがある場合、タスクの切り替えに時間を費やす必要があるためです。2つのタスクを同時に実行すると、アイデアの明確化、ステータスの入力、作業環境の復元などのタスクの切り替えに20％の時間が費やされるということわざがあります。3つある場合、時間の40％がタスクの切り替えに使用されます。並列タスクが多いほど、タスクの切り替えにかかる時間が長くなり、無駄になる人員が増えます。並行タスクが削減された後、無駄な時間が削減され、作業に費やされる時間が増加し、それに応じて全体的な配信効率が向上します。かんばん管理を使用している場合は、各列または各作業区で進行中の作業（並行タスク）の数を制限し、各列のカード数の上限をマークすることができます。
バッチサイズを減らす
これは、アジャイル、最初の配信、最初の試行で提唱されている小さなステップの高速実行です。最初に試行して間違いを修正できます。問題がある場合は、大きなバンプを統合しないように、できるだけ早くそれらを公開できます。終わり、そしてあなたは回復することはできません。
ここで継続的デプロイについて言及する必要があります。多くのチームがJenkinsなどの継続的デプロイツールを使用していると思います。コードが送信されると、Jenkinsワークフローがトリガーされ、コンパイル、テスト、デプロイ、リリースが開始されます。コードを少しずつ送信する必要があります。コードのこの部分はコンパイルされてテストされます。問題がある場合は、できるだけ早く発見できます。問題がない場合は、テストして公式環境に公開した後、できるだけ早く顧客に提供します。
ハンドオーバーの数を減らす
従来のITチームでは、コードは開発の完了から展開、オンラインまでNの複数の部門を通過する必要があります。各部門には、独自のKPIと独自のタスクスケジューリングがあります。異なる部門間の通信にはコストがかかり、作業指示書の承認には時間がかかります。これには時間がかかります。その結果、納期が延長されました。また、部門ごとに機能認識の罠があり、開発が当たり前の期間中は、運用・保守がまったく理解できない場合があります。情報の分離により、いくつかの既知の欠陥が時間内にダウンストリームに送信されない可能性があり、さまざまなリワーク状況が発生する可能性があります。
この引き継ぎを減らすために、自動化された方法を導入してほとんどの操作を完了するか、チームが他の人にできるだけ依存しないように構造を調整することができます。
制約ポイントを継続的に特定して改善する
制約はボトルネックです。チーム全体に制約ポイントがある場合、配信ワークフローにボトルネックが発生します。作業の最適化により、制約ポイントの前の作業が制約ポイントに蓄積され、タスクが到着していないため、制約ポイントの後のロールが待機する場合があります。全体的なパフォーマンスを向上させるには、タスクのスループットを向上させるために制約ポイントを見つけて拡大する必要があります。制約ポイントに向けられていない最適化は幻想です。
通常、以下の手順に従って制約を広げます。
- 制約ポイントを特定します。タスクキューが最も長いロールが制約ポイントです。
- 見つかった制約ポイントに従って、制約ポイントを広げる方法を見つけます。
- 2の決定に従って、全体的な作業を検討します。
- システムの制約を改善します。
- 制約が拡大されている場合は、ワークフロー全体に新しい制約ポイントが表示されます。上記の手順を繰り返します。
バリューストリームのジレンマと無駄を排除する
オープンソースに加えて、配信効率を向上させるために、しかしまた支出を削減する必要があります。顧客のニーズと支払い意思の範囲を超えて、材料とリソースを削減します。
- 半製品：バリューストリームで完全に完了していない作業、およびキューで作業します。部分的に完了した作業は徐々に期限切れになり、最終的には時間の経過とともに価値が失われます。たとえば、未確認の要件やレビュー待ちの変更などです。
- 追加プロセス：顧客に付加価値をもたらさない、配送プロセス中に実行される追加作業。たとえば、ダウンストリームで使用されていないドキュメント、または出力結果に付加価値をもたらさないドキュメントのレビュー。
- 追加機能：納品工程において、組織やお客様にとって全く不要な機能を構築します。まだ金メッキの段階には至っていませんが、金メッキに時間を浪費しています。金メッキ機能は、機能テストや管理の複雑さと作業負荷を増大させます。 。
- タスク切り替え：複数のプロジェクトまたはバリューストリームに担当者を割り当てます。タスク切り替えが発生するため、バリューストリームで追加のワークフローと時間が消費されます。
- 待機中：リソースの競合による待機により、サイクルタイムが長くなり、顧客への配信が遅れます。たとえば、他の部門の協力を待っています。
- 移動：情報またはデータがワークセンター間を移動する作業量。たとえば、同じ場所で仕事をしていない場合に頻繁にコミュニケーションをとる必要がある人にとっては、人員の移動が無駄になります。または、作業の引き継ぎによってモバイルの無駄が発生し、追加の通信が必要になります。
- 欠陥：情報、材料、または製品のエラー、不完全性、またはあいまいさのために、確認するためにある程度の作業が必要です。欠陥が発生してから検出されるまでの時間間隔が長いほど、問題の解決が難しくなります。
- 非標準または手動操作：システムの手動展開など、他の人の非標準または手動作業に依存する必要があります
- フィラー：組織の目標を達成するために、一部の人々やチームは不合理な状況に置かれなければなりません。
上記の8種類の廃棄物を解決することによってのみ、システムの改善はこれらの負担を軽減または排除し、迅速な流れの目標を達成することができます。
ステップ2：フィードバックの原則
最初の作業方法は、作業がバリューストリーム内で左から右に流れるようにすることであり、2番目の作業方法は、右から左への各段階で作業フィードバックを迅速かつ継続的に取得できるメカニズムを作成することです。この方法は、フィードバックループを増幅することで問題の再発を防ぎ、問題検出サイクルを短縮し、障害の迅速な修復を実現できます。私たちの目標は、ソースから品質を管理し、プロセスに関連する知識を組み込むことです。より安全な作業システムを作成し、障害や事故が発生する前に検出して解決し、最終的に安全で信頼性の高い作業システムを確立します。
一般的に、問題を見つけて修正するのに最適なのは、障害が発生したときです。問題が見つかった場合にのみ、問題を解決できます。ワークフローと組織全体で高品質のフィードバックメカニズムを確立することにより、システムを比較的小規模かつ低コストで修復できます。災害前の問題を解消し、組織的な学習環境を作ります。
複雑なシステムで安全に作業する
複雑なシステムの重要な特徴は、システム全体を捉えることができないことです。システム内のさまざまなコンポーネントは通常、緊密に結合され、密接に関連しており、システムの動作をコンポーネントの動作だけで説明することはできません。複雑なシステムには障害が存在し、避けられないため、災害が発生する前にエラーを迅速に検出できるように、エンジニアがシステム内で恐れることなく作業できる安全な作業システム、つまりあらゆる種類のトスを設計する必要があります。ロードシステムをより安全にするために、次の4つの対策を講じることができます。
- 複雑なタスクを管理して、設計と運用の問題を特定します
- 協力して問題を解決し、新しい知識をすばやく構築します
- 組織全体で、地域の新しい知識をグローバルスコープに適用します
- リーダーは、上記の才能を持つ人々を育成し続ける必要があります
問題のタイムリーな検出
時間内に問題を発見したい場合は、一般的に2つのアプローチがあります。受動的に待機する方法と積極的な試行錯誤です。
通常、監視システムを構築し、多次元インジケータを設定し、システムを監視します。システムに障害が発生すると、関係者がアラームメッセージを受信し、アラームメッセージに基づいて問題の特定と解決を開始します。この方法は、障害が発生するのを待つ必要があるため、受動的に待機しています。障害のタイミングは制御できません。職場で発生する可能性があり、就寝中の夜間、週末、休暇などのイベントで発生する可能性が高くなります。結婚や礼拝の時、この方法は避けられません。受動的な待機によって構築された監視システムは、能動的な試行錯誤の基礎です。
積極的な試行錯誤は、安全な作業システムで設計と仮定を継続的に検証することです。このように2つのキーワードは、積極的かつ安全です。検証プロセス中に本番システムを麻痺させた場合、それは冗談になります。これの目標は、システムの情報フローを可能な限り多くの次元から、より早く、より速く、最も低いコストで増やし、問題の原因と結果を可能な限り明確に特定することです。排除できる仮定が多ければ多いほど、問題をより早く見つけて解決することができます。同時に、このプロセスは軍事訓練のプロセスでもあり、よく学び、革新することができます。
問題を克服し、新しい知識を得るために協力する
これは、問題を発見した後、それを解決する必要があるため、「時間内に問題を見つける」ことです。問題を解決するために、すべての関係者を動員して協力する必要があります。問題がある場合、最もタブーとなるのは、問題を回避するか、「十分な時間がない」ことを使用して事前に変化させることです。私たちがしなければならないのは、生産を完全に停止することを躊躇することなく、問題を解決することでもあります。
すべての関係者が問題の解決に関与する必要がある理由については、次の理由があります。
- 問題の特定と対処に関係者が関与することで、誰もがシステムをより深く理解し、避けられない初期の無知な段階を学習プロセスに変えることができます。
- 問題がダウンストリームリンクに持ち込まれるのを防ぐことができます。ダウンストリームリンクに入ると、修理コストと作業負荷が指数関数的に増加し、技術的負債が発生します。
- 新しいジョブの開始を防止します。問題が解決しない場合は、新しい機能が開始され、新しい問題が発生します。
- 問題が解決されない場合、障害が再び発生し、修理コストが高くなります
ソースでの品質を保証します
この点は、主にQA部門と開発部門を対象としており、「汚染者がそれを管理する」という国の政策にいくぶん似ています。日常業務では、バリューストリームの全員が管理領域の問題を見つけて解決する必要があります。このようにして、外部の承認に頼るのではなく、品質管理、安全責任、および意思決定を作業環境に置くことができます。上級管理職。
たとえば、開発者の開発プロセスでは、テストチームに頼る代わりに自動テストを使用できます。このようにして、開発者は必要なときにいつでも自分のコードをすばやくテストでき、自動テストが完了した後、コードをに展開できます。正式な環境。このように、自分自身だけでなく他人にも責任があります。
ダウンストリーム作業用に最適化
これがリーン原則の原因です。最も重要な顧客はダウンストリームです。ダウンストリームの作業を最適化するには、顧客に共感し、迅速でスムーズなフローを妨げる可能性のある設計上の問題をより適切に特定する必要があります。たとえば、開発では、アーキテクチャ、パフォーマンス、安定性、テスト容易性、構成可能性、セキュリティなどの一連の機能など、運用と保守のために独自の作業を最適化する必要があります。これらの最適化タスクは、顧客に機能を提供することと同じくらい重要です。
3番目のステップ：継続的な学習と実験の原則
最初のステップは左から右へのワークフローを確立することであり、2番目のステップは右から左へのフィードバックメカニズムを確立することであり、3番目のステップは継続的な学習と実験の文化を確立することです。個人のスキルを向上させることにより、チームと組織の富。
このステップの核となるのは、信頼性の高い文化を確立することです。この文化は、誰もが継続的な学習者であり、日々の仕事でリスクを冒し、安全な方法で仕事を改善し、製品を開発し、成功または失敗からの経験を蓄積することを強調しています。これにより、価値のあるアイデアを特定し、価値のないアイデアを破棄します。個々の努力は全体の進化を推進し、チーム全体が新しいテクノロジーと方法を試し、実践するのを助けます。
必要な慣行には、イノベーションの文化の創造、リスクを冒すことを敢えて（恐れや命令への盲目的な服従とは対照的に）、高い信頼（低い信頼と指揮統制とは対照的に）、開発とITの少なくとも20％を割り当てることが含まれます運用および保守サイクル非機能要件を与え、改善を奨励し続ける
学習組織と安全文化を確立する
複雑なシステムでは、結果を正確に予測することは非現実的です。言い換えれば、どんなに注意を払っても、常に失敗が発生します。
Westrumモデルは、次の3種類の組織文化を提案しています。
- 病理組織は多くの恐れと脅威を特徴とし、失敗を隠す傾向があります。
- 官僚機構は厳格なルールと手続きが特徴であり、各部門には独自の玄関口があります。この組織では、事故は審査システムによって処理され、優雅さと強さの組み合わせが採用されています。
- バイオエンジニアリング組織は、積極的に情報を調査し、共有します。この組織では、チーム全体のすべての従業員が責任を共有し、事故を積極的に振り返り、根本原因を見つけます。
3番目のステップは、生産モデルの編成を促進することです。チームは、障害が発生した場合、人々の問題を調査するのではなく、事故が再発しないように安全なシステムを設計する方法に焦点を合わせます。EtsyのエンジニアであるBethanyMacriは次のように述べています。「責任を負わなければ、恐れはありません。恐れがなければ、正直になれます。正直に言うと、事故を効果的に防ぐことができます。」
日常業務の改善を制度化する
技術的価値の流れでは、壊滅的な事故の発生を防ぐために、チームはさまざまな一時的な解決策を実装する作業に陥り、それらの貴重なタスクを完了する時間がありません。したがって、一時的な解決策で問題を解決するモデルは、問題と技術的負債の蓄積につながります。したがって、技術的負債の返済、バグの修正、コードのリファクタリングと最適化など、日常業務を改善するために日常業務に時間を確保する必要があります。これには、チームが開発間隔の期間を確保する必要があります。チームメンバーに問題の解決を許可します。ある事柄の結果は常に別の事柄の原因です。私たちは日々の問題を解決して、潜在的なリスクの発見と解決を支援したり、より意味のあることを行うためのより多くのエネルギーを持っています。
ローカルディスカバリーをグローバル最適化に変える
ローカルディスカバリーをグローバル最適化に変換するということは、チームが最初に金持ちになり、次に金持ちになる必要があることを意味します。単一のチームまたは個人が独自の知識または経験を獲得した場合、この暗黙知（文書やコミュニケーションを通過するのが難しい知識）を形式知に変換し、グローバルな知識ベースを確立して集合的な知恵を形成する必要があります。他の人が同様の仕事をするとき、彼らは前任者の経験を素早く見つけるために知識ベースを検索する必要があるだけです。
日常業務に柔軟性を注入する
これの目標は、チームまたはシステムの回復力を高め、脆弱性に対する耐性を向上させることです。脆弱性に抵抗したい場合は、脆弱性がどこにあるかを知る必要があります。以前の経験に基づいて、展開方法を短縮し、テストカバレッジを改善し、テスト実行時間を短縮し、システムを分離することで、システムの復元力を向上させることができます。ネットワークケーブルをランダムに抜いたり、電源を切ったり、プロセスを強制終了したりするなどの障害ドリル（NetflixのChaos Monkeyなど）を通じて、システムの復元力を確認できます。圧力テスト（単一インターフェース、フルリンク）を通じて、システムのボトルネックと上限をテストすることもできます。
リーダーシップは学習文化を強化します
これはリーダーのためのものです。優れたリーダーシップは、すべての決定を正しく行うことに反映されるのではなく、チームが日常業務でこの種の卓越性を感じることができるようにチームの条件を作成することに反映されます。リーダーは個人的に最前線の仕事に参加しないため、最前線の労働者は大規模な組織環境を理解していないか、作業領域外で変更を加える権利がありません。したがって、リーダーと最前線の労働者の関係は補完的であり、お互いを尊重しなければなりません。
やっと
DevOpsをサポートする基本原則として、DevOpsの3ステップの方法は、DevOpsの動作とモードも導き出します。多くのチームがすでにDevOpsの道を歩み始めていると思います。次の4つの段階がリストされています。
- DevだけがOpsを持っておらず、すべてのものは自分で開発されています。
- DevとOpsがあり、それらは互いに独立しています。Opsは、コードの開発を除くすべての作業を引き受けます。
- Dev + Ops、Opsは効率を改善するためにいくつかの自動化ツールを作成しましたが、それらは主に独自の使用のためであり、開発のためではありません。
- DevOps、アップストリーム作業の開発では、ダウンストリームの運用と保守によって提供されるシステムまたはプラットフォームを使用して、APIセルフサービスを介して自動的に対応する作業を完了します。
現在の段階を確認できます。まだ到達していない場合は、上記の3段階の作業方法を参照して、DevOpsを段階的に実装できます。
個人ホームページ：https://www.howardliu.cn
個人ブログの記事：三段階の作業方法は、DevOpsチーム実現する
：CSDNホームページhttp://blog.csdn.net/liuxinghao
CSDNのブログ記事を：3つのステップの作業方法をDevOpsを実現する