時間の簡単な歴史

理解するために DevOps 、プログラマーしかいなかった老後を遡る必要があります。

として タオ 私たちに教えます：

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

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

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

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

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

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

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

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

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

パワーピボットとピボットテーブル

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

Javaのメモリリークとは何ですか

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

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

ソフトウェアプロジェクトは失敗しやすくなり、業界標準として受け入れられました。統計によると、プロジェクトの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、ネットワークエンジニア、セキュリティの専門家などを含む「運用」に送信されました。 開発者 そして Ops の主な推進力です DevOps 。

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

の最良の説明 DevOpsソリューション によって与えられます ジーン・キム 、およびまだ読んでいない場合 フェニックスプロジェクト 少し時間をかけてやってみることをお勧めします。

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

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

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

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

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

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

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

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

銀行カードをハッキングする方法

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

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

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

レーン2-ギアアップ

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

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

自分にハイタッチをするのは簡単ですが、フィードバックを求めてフィードバックを与えることは、実際の状況を確認する方法です。ダウンストリームの各小さなステップの後に、すぐにアップストリームの確認が続くことが不可欠です。

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

レーン3-ワープ10

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

ただし、動きを組み合わせる前に、まず個々のステップをマスターする必要があります。

「マスターにとって適切なことは、初心者にとっては適切ではありません。構造を超越する前にタオを理解する必要があります。」

cssでflexboxを使用する方法

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

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

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

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

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

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

結論

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

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

関連： ギャップを埋める：DevOpsコミュニケーションの重要性