DevOpsはメソッドでもツールでもありません。それは文化です



DevOpsは、設計から開発プロセス、生産サポートに至るまで、サービスライフサイクル全体に一緒に参加する運用エンジニアと開発エンジニアの実践です。システムに敏捷性をもたらすことは、DevOps文化と見なすことができます。

文化はしばしば無視され誤解されますが、それでも企業の業績を左右する重要な要素です。私たちの文化を管理しないと、間違った慣行を行うことになり、最終的にはビジネス目標に影響を及ぼします。

組織の現在の文化を理解する

文化は、グループまたは企業内の価値観と規範について教えてくれます。それは、何が重要であるか、そして人々がどのように互いにアプローチし、働くかを特定します。





CULTURE =「成功のために物事を賢く行う方法」

カスタマーサポートチームの例を見てみましょう。そのチームの文化は、最終的に顧客満足度の97〜98%を達成するようなものでなければなりません。



顧客の喜びを視野に入れて、まず第一に、彼らは礼儀正しくする必要があります。困難な状況でも、混乱を避けるために、要件に応じて作業に優先順位を付ける必要があるため、聞き上手である必要があります。

少し一時停止して、いくつか質問してみましょう。

  • 今の私の会社の文化は何ですか?
  • この文化は私のビジネス目標またはKRAとどの程度一致していますか?
  • ミスアライメントによりどのような問題が予想されますか?

すべての組織にとって、4Cは重要な役割を果たします



組織の4C

それでは、ソフトウェア開発組織の文化を見てみましょう。単一のソフトウェアユニットの構築と保守には多くのチームが関わっています。これらのチームはすべて、別々の目標と別々の文化を持っています。

このプロセスは、要件がクライアントによって確認された後に開始されます。

開発者は、組織によって定義されたコーディングガイドラインに従い、コンパイラ、インタプリタ、デバッガなどのプログラミングツールを使用してコードを生成します。コーディングには、C、C ++、Pascal、Java、PHPなどのさまざまな高級プログラミング言語が使用されます。

彼らは完全なパッケージを小さなフォルダに分割し、それに応じて小さなコードを開発します。

ステージ1 :これらの小さなコード単位は、クラブ化されて大きな単位を形成します。小さなチップを統合する際には、統合テストと呼ばれるプロジェクトレベルのテストを実行する必要があります。

Javaでオブジェクトの配列を宣言する

ステージ2 :統合が成功すると、ダミーシステムにデプロイされます。このダミーシステムは、クライアントマシンまたはこのプロジェクトを最終的に展開する必要のあるマシンと同様の構成になっています。

ステージ3 :最後に、ダミーシステムですべての機能をテストした後、プロジェクトを運用サーバーまたはクライアントマシンに展開します。

このプロセスは言葉では非常にスムーズで簡単に見えますが、技術的には達成するのは非常に困難です。

直面する可能性のある問題を見てみましょう。

ステージ1

クライアントは常に製品の品質を向上させるための変更を探しています。最初の反復が行われたほとんどの場合、クライアントはいくつかの変更を提案します。開発者が変更を受け取ると、それらの組み込みが開始され、統合に影響を与えてビルドが壊れます。

ステージ2:

ほとんどの場合、テスターや他の運用担当者は、行われる新しい変更に気づきません。開発者からコードを入手するとすぐに、テストを開始します。バックエンドにいる間、開発者はまだ変更を加えています。

新しい変更を実装するのに十分な時間がないため、他のネットワークやデータベースの問題に直面する非効率的なコードを開発することになり、配信時間が再び遅れます。

最終的にコードを運用チームに提供すると、新しいテストケースを作成して実装するための時間が最小限に抑えられます。そのため、彼らは、後で優先度が高いことに気付いたテストケースの多くをスキップします。

ステージ3:

事実上、ビルドは本番環境に移行する準備ができているように見えますが、結果はまったく予想外です。ビルドが失敗し、いくつかのバグが発生します。

次に、発生したすべてのバグについて、発生した理由、発生した場所、それを克服するためにどのような変更を行う必要があるか、以前のコードと互換性を持たせるために他のコードに変更があるかどうかを追跡する必要があります。最後に、これらすべてのバグについて、バグレポートを生成する必要があります。

Javaの例の可変クラス

この失敗は、データベース開発者がコードの効率を知らないこと、テスターがテストケースの数を知らないことなどによるシステムエラーが原因です。

クライアントは常に締め切りを厳しくしているので、それらを達成するために関与する従業員は、全体的な品質を妥協しなければならない場合でも、最終リリースにのみ集中します。

これは仕事の調整の問題のようですが、 これは実際に採用された文化の失敗です。

これは、手動プロセスに大きく依存しているために発生します。異なる分野の知識の欠如、アクセスの欠如、または興味の欠如のために同じチームを行き来することは、私たち自身の負担と苦痛を増大させます。

多才である必要がある時が来ました。システムに関係するすべてのプロセスをマスターするのは難しいかもしれませんが、私たちはすべてのジャックになり、そのうちの1つをマスターすることができます。そうすれば、システムを自動化するか、ロールバックではなく回復するのに十分なインテリジェントにすることができるのは私たちだけです。

今、あなたはなぜ考えているのでしょうか?

それは、あなたが習得しているものが他の人に大きく依存しているからです。したがって、依存点について知るには、システム全体を理解する必要があります。

それでは、文化を変えるプロセスについて考えてみましょう。その前に、以下の質問に対する答えがありますか?

  • あなたの現在の文化はどこで失敗しますか?
  • なぜプロセスを変更したいのですか?
  • 必要なすべての変更を明確に特定しましたか?
  • 影響を受けるすべての利害関係者からフィードバックと賛同を得ましたか?
  • 変更のためのプロセス規律、データ、および測定システムを再検証しましたか?

ですから、私たちがすべての答えを得るとき、私たちは私たちのシステムへの革命を考えます。この革命はどのように起こりますか?それは私たちが今あるものを殺したときにのみ達成することができます。チーム間のコードの移行には多くの時間が無駄になります。継続的インテグレーションと継続的デプロイを実行できるプロセスを導入する必要があります。

継続的インテグレーションとデプロイメントのこのプロセスにより、俊敏性が向上します。この敏捷性をもたらすことは、DevOps文化であると考えられています。

DevOpsは、設計から開発プロセス、生産サポートに至るまで、サービスライフサイクル全体に一緒に参加する運用エンジニアと開発エンジニアの実践です。

時間の経過とともに作業システムを変更することは容易ではありません。移行を成功させるには、システムを再構築するのではなく、システムを刷新する必要があります。

それでは、これを実現する方法を見てみましょう。アプローチには2つの方法があります。

1)上から下へ

2)ボトムアップ

これらの手法を深く掘り下げていくと、どちらが組織に最も適しているかがわかります。

トップダウンアプローチでは、上級管理職に行き、すべてのチームにわたって変更を加えるように依頼することができます。経営陣が納得すれば、私たちはそれに取り組み始めることができます。

しかし、「いいえ」と答えられる可能性はかなり高いです。システムを変更すると、組織が不安定になる可能性があるためです。

彼らは、組織の構造、収益、クライアントの関心レベルなどを調べる必要があります。しかし、古いシステムから抜け出すことから彼らを引き戻す最も重要な要因は、彼らが見ることができないことです。 何が達成できるか、そしてそれが新しいものでどれほどスムーズに達成できるかについての全体像。

この場合、この全体像を把握するための2番目のアプローチを探すことができます。

ボトムアップアプローチでは、ボランティアが必要です。ここでは、小さなチームと小さなタスクを取り、DevOpsモデルで実行する必要があります。

このモデルの技術的な側面を調べると、作業をより効率的かつ高速にするさまざまな洗練されたツールのセットがあります。ただし、ツールだけでは、DevOpsと呼ばれるコラボレーション環境を作成するのに十分な能力はありません。

このような環境を作成するには、箱から出して考える必要があります。チーム、ビジネス、顧客について人々がどのように考えているかを評価し、再調整します。

新しいツールセットをまとめるのは、組織文化を変えるよりも簡単です。反社会的マスター開発者を促進し、非効率的なコードを統合できるようにし、適切にテストされていないコードを展開し、お互いの頭を非難し、運用チームが愚かであると考えることは、ビジネスを可能にするために私たちが従うベストプラクティスではありませんお客様に価値を創造します。

プロセスを複雑にするのはツールではなく、ツールを使用する人々です。 アイデアや行動を収集するのではなく、抽象的なレベルで言うと、それらにオープンであることが私たちを明るい道へと導きます。

6人のメンバーと3ポイントのストーリーのチームから始めましょう。まず、開発者、運用、テスターなどと呼ばれるチームを壊す必要があります。「DevOps」と言うと、それらすべてを1つと見なします。要件を受け取ったら、リスクゾーンを分析する必要があります。海とヘリのより深い部分を念頭に置いて..私たちは航海を開始します。

ここで、「失敗の可能性を減らすこれらの継続的インテグレーションと継続的デプロイのxファクターは何か」を考えている必要があります。

人工知能の最新技術

ビジョンとプロセスが改善されたことで、プロセスがいかにスムーズであったか、失敗のリスクがどのように減少したか、タイムラインの前にタスクがどのように完了したかなど、結果を明確に把握して経営陣にアプローチできます。

これで、各反復の後に振り返ることで、技術的および文化的根拠に基づいてプロセス全体がどのように最適化されたかを明確に視覚化できます。

エドゥレカは特別にキュレーションしました これは、Puppet、Jenkins、Ansible、SaltStack、Chefなどの概念を習得するのに役立ちます。

質問がありますか?コメントセクションでそれらに言及してください。折り返しご連絡いたします。

関連記事: