私が大学に入学したばかりの頃は、ソフトウェアエンジニアリングという専攻が人気だったと記憶していますが、この専攻は海外のチュートリアルを利用しており、授業料も平均的な専攻の1.5倍程度とかなり高額だったので、昔から人気がありました。ソフトウェアを使用するのは非常に複雑で、ハイエンドだとさえ感じます。
後で「神話の人月」を読んだのですが、正直に言うと、ソフトウェア開発に特効薬はないという一文を思い出しましたが、これはソフトウェアが簡単ではないことを改めて証明しています。(余談になりますが、この本は大学で学んでいる学生や開発に携わっている学生にとっては少々敷居が高く、抽象的すぎるということです。比較的大きなプロジェクトに個人的に参加して初めて理解が深まります。)
長年にわたり、CMM モデル、アジャイル開発、devops を経験し、数千人が開発するプロジェクトに参加し、また数人で小規模なプロジェクトにも取り組み、開発、プロジェクト管理、プロダクトなど、さまざまな役割を果たしてきました。 , ビジネス担当者などはもう少し経験があり、最も一般的なDevopsの実行方法を説明します。
もちろん、私はエンジニアリングの効率化の専門家ではありません。また、この記事はソフトウェア エンジニアリングの方法や DevOps の方法について説明するチュートリアルではありません。中心となるのは、devops の価値、いくつかの重要な事前要素、およびその背後にあるロジックについて議論することです。
Devops 実装によってもたらされる直接的な価値を見てみましょう。
顧客への価値: より迅速な対応
機能ごとにリリースすると、機能のリリースに数日かかる場合があります
顧客ニーズへのより迅速な対応
製品価値: 品質の向上
毎回のリリース範囲を減らし、エラーの確率を減らし、品質を向上させる
問題が発生した場合は、ロールバックまたは迅速な修復を通じて時間内に対応し、製品の品質を向上させます。
チームにとっての価値: 組織の活性化、管理の簡素化、パフォーマンスの向上
合理的な解体を通じて結合度が減少し、フィールドを世帯ごとに分割することでチームの熱意が向上し、大きな食堂での食事やお互いの待ち時間が減り、コンテキストの切り替えによるパフォーマンスが低下します。チームメンバーにとっても成長が早く、責任も持てるのでとても助かります。
マネージャーにとっては、非効率な組織コラボレーションから解放され、より高いレベルのビジネスチャンスやプロジェクトの機会に焦点を当てることができます。
開発と運用保守の間の境界を開き、コンテキストの切り替えを減らします。さらに、適切なマイクロサービス分割により、単一タスクの難易度が低くなります。
ソフトウェアの変更を実装することは実際には単純な要件ではなく、システム エンジニアリングが必要です。devops にはいくつかの重要な前提条件があります。
マイクロサービスアーキテクチャの分割
CI/CD ツール
グレースケール環境
チーム文化の変革: アイデアの認識、作業方法の変更の認識、T 字型人材の継続的な育成
多くのチームが開発モードの変革の問題に直面しているとき、私の提案は次のとおりです。
早期の導入は、後期の導入よりも優れています。早期の導入は、顧客とビジネスへの負担が少なくなります。
詳細に計画するよりも、すぐに実行する方が良いでしょう。
個人の開発効率の差が比較的大きいため、帯域幅の見積もりは非常に困難です。そのため、組織のポテンシャルを活性化することに比べて、詳細な帯域幅の見積もりの値ははるかに小さくなります。
計画は必要ですが、ビジネスは急速に変化し、機敏な組織の方が価値があるため、すべてを詳細に計画するよりもすぐに実行する方が価値があります。
巨視的な全体計画が必要、そうでないと方向性が見えなくなる
1 つまたは複数のモジュールから始めて、徐々に練習して経験を積むことを検討してください。最も重要なことは、チームメイトの文化の変革であり、全員が新しいモデルを理解し、受け入れることです。
これまで、Devops の学問に戻ってその本質を定義しながら、ワイルドな実践方法についてたくさんお話してきましたが、「CALMS」というテーマがあります。
文化 - 変化を受け入れ、コラボレーションとコミュニケーションを促進することを指します
自動化 - バリューチェーンから人間の介入を取り除くことを指します。
リーン - 高周波サイクルを駆動するためのリーン原則の使用を指します。
メトリクス (指標) - 各リンクの測定を指し、データを通じてサイクルを改善します。
共有 - 成功と失敗を率直に他の人と共有し、間違いから学ぶことを指します
上で述べたことがCALMSにマッピングできることがわかり、比較してみるとさらに理解が深まります。
上記のさまざまな価値に加えて、devops のより大きな価値は人間性の刺激にあると思います。従来のアジャイルモデルやCMMモデルとの最大の違いは、管理ロジックの違いにあります。この違いがデータベースの古典的なロックによって説明される場合、それは実際には楽観的ロックと悲観的ロックの違いです。さまざまなツールやルーチンに加えて、devops の中核は、個々のチームのアクティブな所有者意識を活性化できることです。メンバーたちに果敢に戦わせてやりましょう。
では、DevOpsは終わりになるのでしょうか？ソフトウェア エンジニアリング管理は、より高い生産性を実現するために進化し、発展し続けるでしょう。