DevOpsとは何ですか？

時間の簡単な歴史

DevOpsを理解するには、プログラマーしかいなかった古い時代にさかのぼる必要があります。

タオが教えてくれるように：

昔のプログラマーは神秘的で深遠でした。 私たちは彼らの考えを理解することができないので、私たちがすることは彼らの外見を説明することだけです：

• キツネが水を渡るような気づき
• 戦場の将軍のように警告
• 親切な、ホステスがゲストに挨拶するように
• 刻まれていない木のブロックのようなシンプルな
• 暗い洞窟の黒いプールのような不透明な

プログラマーは機械語を生み出しました。 機械語はアセンブラーを生み出しました。 アセンブラはコンパイラを生み出しました。 今では何千もの言語があります。 それぞれの言語には目的がありますが、謙虚です。 各言語は、ソフトウェアの陰と陽を表現しています。 各言語は、ソフトウェア内でその場所を持っています。

当時、ソフトウェア開発オフィスは主にラボと呼ばれ、プログラマーは科学者でした。 優れたアプリケーションを作成するには、プログラマーはアプリケーションが解決している問題を完全に理解する必要がありました。 彼らは、アプリケーションがどこで使用され、どのようなシステムで実行されるかを知る必要がありました。 本質的に、プログラマーは、仕様から開発、展開、サポートに至るまで、アプリケーションについてすべてを知っていました。

そして、人間の本性が始まり、私たちはもっと多くを求め始めました。 より多くの速度、より多くの機能、より多くのユーザー、より多くのすべて。

謙虚で謙虚で平和な生き物であるプログラマーは、常にもっと多くを求めている貧しいユーザーの爆発を乗り切るチャンスがほとんどありませんでした。 勝つための最良のチャンスは、さまざまな方向に進化し始め、カーストを作成することでした。 すぐに、プログラマーは、開発者、ソフトウェアエンジニア、ネットワーク管理者、データベース開発者、Web開発者、システムアーキテクト、QAエンジニアなどと呼ばれる新しい種類の祖先として絶滅しました。 急速に進化し、外の世界からの挑戦に適応することは、彼らのDNAの一部になりました。 新しいカーストは数週間で進化する可能性があります。 Web開発者は、バックエンド開発者、フロントエンド開発者、PHP開発者、Ruby開発者、Angular開発者になりました…すべてが地獄に落ちていました。

すぐに彼らは皆、彼らが同じ父親であるプログラマーから来たことを忘れました。 世界をより良い場所にしたいと思っていた、シンプルで平和な科学者。 彼らはお互いに戦い始め、それぞれが「プログラマー」の真の子孫であり、彼らの血は他のものよりも純粋であると主張しました。

時間が経つにつれて、彼らは彼らの相互作用を最小限に抑え、本当に必要なときにだけお互いに話しました。 彼らは遠い家族の成功を祝うのをやめ、最終的には時々はがきを送るのをやめました。

彼らが自分の気持ちだけを調べれば、プログラマーの火花が彼らの心の中にあり、輝きを放ち、銀河に平和をもたらすのを待っていることに気付くでしょう。

世界を征服するための利己的で自己中心的な競争の中で、プログラマーの子孫は彼らの仕事の目的そのもの、つまりクライアントの問題を解決することを忘れていました。 クライアントは、プロジェクトが遅れたり、費用がかかりすぎたり、失敗したりするなどの行動の痛みを感じ始めました。

時々、明るい星が輝き、誰かが子孫の間で平和を作ろうとするインスピレーションを得るでしょう。 彼らは滝を思いついた。 これは、さまざまな開発者グループが必要な場合にのみ通信するという事実を利用した素晴らしいアイデアでした。 あるグループが仕事の一部を終えると、次のグループと連絡を取り、プロセスを通じて作業を送信し、それを振り返ることはありませんでした。

これはしばらくの間は機能しましたが、いつものように、人間（クライアント）はもう一度もっと欲しかったのです。 彼らは、ソフトウェア作成の全プロセスにもっと積極的に参加し、より頻繁に意見を述べ、手遅れになった場合でも変更を求めたいと考えていました。

ソフトウェアプロジェクトは失敗しやすくなり、業界標準として受け入れられました。 統計によると、プロジェクトの50％以上が失敗しており、それについては何もする必要がないようです（ZDNet、CNet）

すべての世代には、これらすべての開発者グループが協力し、コミュニケーションを取り、クライアントが可能な限り最高のソリューションを確実に受け取れるように柔軟に対応する方法を見つける必要があることを知っている、オープンマインドな個人が数人いました。 偉大なジョン・フォン・ノイマンの同僚による、早くも1957年のこれらの試みの痕跡があります。 しかし、2001年の初めに革命を開始するまで待たなければなりませんでした。そのとき、ダーティダースがアジャイルマニフェストを作成しました。

アジャイルマニフェストは、12の原則に基づいています。

1. 貴重なソフトウェアの早期かつ継続的な提供による顧客満足
2. 開発が遅れた場合でも、要件の変更を歓迎します
3. 動作するソフトウェアは頻繁に配信されます（数か月ではなく数週間）
4. ビジネスマンと開発者の間の緊密な毎日の協力
5. プロジェクトは、信頼されるべきやる気のある個人を中心に構築されています
6. 対面での会話はコミュニケーションの最良の形態です（コロケーション）
7. 動作するソフトウェアは進歩の主要な尺度です
8. 持続可能な開発、一定のペースを維持することができる
9. 技術的な卓越性と優れたデザインへの継続的な注意
10. シンプルさ（行われていない作業の量を最大化する技術）は不可欠です
11. 自己組織化チーム
12. 変化する状況への定期的な適応

アジャイルマニフェストは、銀河に平和をもたらし、フォースのバランスを取り戻すための最初の大きな一歩でした。 非常に長い間初めて、ソフトウェア開発プロセスですべての利害関係者をつなぐことは、手続き的で機械的な方法と同様に、文化的で「人間的な」方法に基づいていました。 人々はお互いに話し合い、定期的に会い、常にアイデアやコメントを交換し始めました。 彼らは自分たちが思っていたよりもはるかに多くの共通点があることに気づき、クライアントは、送金して質問をしないと期待されていた外部要因だけでなく、チームの一員になりました。

克服しなければならないハードルはまだいくつかありましたが、未来はこれまで以上に明るいように見えました。 アジャイルであることは、オープンであり、絶え間ない変化に順応することをいとわないことを意味します。 ただし、変更が多すぎるため、最終的な目標と実現に集中し続けることは困難です。 そして、それがリーンソフトウェア開発が実現した方法です。

LSD（しゃれを意図したもの）に夢中になり、追放されて追放される危険を冒して、一部の子孫はカーストとソフトウェア業界以外の解決策を探しました。 彼らは大手自動車メーカーの仕事に救いを見出しました。 トヨタ生産方式はそのシンプルさの点で驚くべきものであり、そのリーン生産方式がソフトウェア開発に簡単に適用できることは明らかでした。

リーンには7つの原則があります。

1. 無駄をなくす
2. 品質を構築する
3. 知識の創造（学習の増幅）
4. コミットメントを延期する（できるだけ遅く決定する）
5. できるだけ早く配信する
6. 人々を尊重する（チームに力を与える）
7. 全体を最適化する

アジャイルに加えて、リーン原則は、プロセス全体を通して柔軟でありながら、メンタリティと正しいことを行うことに焦点を当てることをサポートしました。

アジャイルとリーンがソフトウェア開発チームに採用されると、原則のすべてをIT全体として適用するために、あと1つのステップが必要になりました。これにより、最終的にDevOpsが実現しました。

DevOpsに入る-3車線の高速道路

ソフトウェア開発チームの昔ながらの見方には、ビジネスアナリスト、システムアーキテクト、フロントエンド開発者、バックエンド開発者、テスターなどが含まれていました。 アジャイルとリーンの原則を含むソフトウェア開発プロセスの最適化は、主にこれらに焦点を合わせていました。 アプリケーションが「本番環境に対応」すると、システムエンジニア、リリースエンジニア、DBA、ネットワークエンジニア、セキュリティプロフェッショナルなどを含む「運用」に送られました。DevとOpsの間の大きな壁を取り除くことが、 DevOpsの主な推進力です。

DevOpsは、ITバリューストリーム全体にリーン原則を実装した結果です。 ITバリューストリームは、元のプログラマーの子孫であるすべての「遠い親戚」を組み合わせて、開発を本番環境に拡張します。

DevOpsソリューションの最良の説明は、Gene Kimによって提供されています。フェニックスプロジェクトをまだ読んでいない場合は、時間をかけて実行することをお勧めします。

DevOpsエンジニアを雇うべきではなく、DevOpsをITの新しい部門にするべきではありません。 DevOpsは文化、考え方であり、全体としてITの一部です。 ITをDevOps組織にするツールはありません。また、自動化のレベルによって、チームがクライアントに最大の価値を提供できるようになることもありません。

DevOpsは通常、3つの方法の方法と呼ばれますが、私はそれらを同じ高速道路の3つの車線と見なしています。 レーン1から始めて、スピードを上げてレーン2に切り替え、最終的に3番目のレーンでスピードを出します。

• レーン1-システム全体のパフォーマンスが主な焦点であり、システムの個々の要素のパフォーマンスよりも強調されます

• レーン2-上流に送信される一定のフィードバックループがあり、無視されないことを確認します

• レーン3-実験を育て、絶え間なく改善し、早く失敗する

レーン1-スピードを上げる

システム全体の重要性を理解し、作業項目に適切な優先順位を付けることは、IT組織がDevOpsの原則を採用するときに最初に学ばなければならないことです。 ITバリューストリームの誰もがボトルネックを作成して作業の流れを減らすことは許可されていません。

中断のないワークフローを保証することは、プロセスに含まれるすべての人にとっての究極の目標です。 人やチームの役割に関係なく、システムを深く理解することが不可欠です。 この考え方を採用すると、ボトルネックが発生するため、欠陥がストリームに送信されることはないため、品質に直接影響します。

作業が停止していないことを確認するだけでは不十分です。 生産的な組織は、常にフローを増やすように努める必要があります。 フローを増やすための方法論は数多くあります。 制約の理論、シックスシグマ、リーン、またはトヨタ生産方式で解決策を見つけることができます。 これらのいずれかを自由に選択するか、独自のものを考え出すか、またはそれらを組み合わせてください。

システムアーキテクト、DBA、QA、またはネットワーク管理者の場合、DevOpsの原則はあなたがどのチームに属しているかを気にしません。 同じルールがすべての人に適用され、すべての人が2つの単純な原則に従うことが期待されます。

• システムフローを中断しないようにします
• ワークフローを常に増やして最適化する

レーン2-ギアアップ

中断のないシステムフローは一方向であり、開発から運用に至ることが期待されます。 理想的な世界では、これはソフトウェアが高品質で迅速に作成され、本番環境に展開され、クライアントに価値を提供することを意味します。

ただし、DevOpsはユートピアではありません。一方向の配信が可能であれば、ウォーターフォール方式で十分です。 成果物を評価し、フローを伝達することは、品質を保証するために非常に重要です。 実装する必要がある最初の「アップストリーム」通信チャネルは、OpstoDevです。

自分にハイタッチをするのは簡単ですが、フィードバックを求めたりフィードバックを与えたりすることは、実際の状況を確認する方法です。 下流の各小さなステップの後に、即座に上流の確認が続くことが不可欠です。

フィードバックループをどのように確立するかは重要ではありません。 開発者をサポートチームミーティングに招待するか、ネットワーク管理者を毎週のスプリント計画に参加させることができます。 フィードバックがあり、コメントが収集されて処理されている限り、組織はDevOps高速道路の速度を落としています。

レーン3-ワープ10

DevOpsの高速レーンは気の弱い人向けではありません。 DevOpsの高速レーンに乗るには、組織が十分に成熟している必要があります。 それはすべて、リスクを冒して失敗から学び、継続的に実験し、繰り返しと実践が習得の前提条件であることを受け入れることです。 カタという言葉をよく耳にしますが、これには理由があります。 継続的なトレーニングと繰り返しは、複雑な動きを日常的にするため、習熟につながります。

ただし、動きを組み合わせる前に、まず個々のステップをマスターすることが不可欠です。

「マスターにふさわしいことは、初心者にはふさわしくありません。 構造を超越する前にタオを理解する必要があります。」

DevOps Third Way / Fast Laneには、毎日の継続的な実験のための時間の割り当て、リスクを冒したことに対するチームへの絶え間ない報酬、および回復力を高めるためのシステムへの障害の導入が含まれます。

これらの種類の対策を実装するときに組織が内破しないようにするには、すべてのボトルネックが明確でシステムフローが中断されないようにしながら、すべてのチーム間で頻繁にフィードバックループを作成する必要があります。

これらの対策を実施することで、組織は常に警戒を怠らず、課題に迅速かつ効果的に対応できるようになります。

概要-DevOps組織のチェックリスト

これは、 DevOpsがIT組織をどのように有効化したかを検証するために使用できるチェックリストです。 どうぞ、記事にコメントして、あなた自身のポイントを追加してください。

• 開発チームと運用チームの間に壁はありません。 どちらも同じプロセスの一部です
• あるチームから別のチームに送られる作業は常に検証され、最高品質です
• 作業の「積み重ね」はなく、すべてのボトルネックが処理されます
• 展開と保守は同じタイムボックスの一部であるため、開発チームはその活動に運用時間を使用していません
• 開発チームは金曜日の午後5時に展開用のコードを提供せず、週末に作業をクリーンアップするための操作を残します
• 開発環境は標準化されており、運用ではそれらを簡単に再現して本番環境に拡張できます
• 開発チームは適切と判断した新しいバージョンを提供でき、運用部門はそれらを本番環境に簡単にデプロイできます
• すべてのチーム間に明確なコミュニケーションラインがあります
• すべてのチームメンバーは、システムの改善に実験して取り組む時間があります
• 欠陥はシステムに定期的に導入（またはシミュレート）され、処理されます。 各実験から学んだ教訓は文書化され、すべての関係者と共有されます。 インシデント処理は日常業務であり、ほとんどの場合、既知の方法で処理されます

結論

Chef、Docker、Ansible、Packer、Troposphere、Consul、Jenkins、SonarQube、AWSなどの最新のDevOpsツールを使用しても、DevOpsの原則を適用しているわけではありません。 DevOpsは考え方です。 私たちは皆同じプロセスの一部であり、同じ時間を共有し、一緒に価値を提供します。 ソフトウェア配信プロセスに参加するすべての人は、システム全体の速度を上げたり下げたりすることができます。 開発中に作成されたバグは、システムをダウンさせたり、ファイアウォール構成を誤ったりする可能性があります。

すべての人がDevOpsの一部であり、組織がそれを理解すると、それを管理するのに役立つツールとテクノロジースタックが魔法のように現れます。