最初は痛みがありました。 さまざまなチームを悩ませる多くの問題領域があり、管理部門の既存のパラダイムでこれらの問題を「友人または敵」の一族（開発者-サポート）に排除することはできませんでした。 変更が導入されるスピードはありませんでした-重要なパッチをインストールするのに1日以上かかり、大きなリリースについては言うまでもありません...日。 レベル44の専門家は、貴重な時間を費やして手動でアップデートをインストールしました。 更新のロールバックは、時間内に予測不能でした。 法的登録プロジェクトの形をしていないイニシアチブは、イニシエーターのカリスマ性にもかかわらず、簡単に埋めることができます-隣接ユニットでのイニシアチブを拒否したり、そのような一時停止にした後、アイデアに戻ることは無意味でした-市場「左」。 一方、規制、手順、承認なしに大規模な組織に存在する方法は、カオスを合理化するために作成されたが、官僚主義に変わったのでしょうか？
この座標系では、市場投入までの時間を短縮することに着手しました。 市場では、当時、DevOpsのテーマは非常にファッショナブルでした。 結局のところ、ストーリーは自動化だけでなく、チーム内の関係についてでもあります。 私たちは自分で試してみることにしました。 開発、サポート、インフラストラクチャ部門の責任者は、新しいイデオロギーの開発と推進に取り組んでいます。 Rifeの次のIT会議で、リーダーたちは大声で言ったが、もはや後戻りすることはできなかった。彼らはシステム形成の変化に「サブスクライブ」した。 「目標が設定され、計画が設定され、仕事のため、仲間のために」と思われますが、すべてがうまくいきませんでした。 神話は言葉の後に現れました...人類の夜明けのように、周りで起こっていたことは意味で満たされ、恐怖に満ちた心であり、出来事は他の人の経験のプリズムを通して知覚されました。 喫煙室では、何もしない50の理由すべてを聞くことができます。そして、昔ながらのタバコを手に持っているか、アークと
最終的に、DevOpsを中心に発展した神話が研究され、コレクションに組み込まれました。
| DevOps Raiffeisenbankの神話 | |
 | すでにDevOpsを開始しています |
| DevOpsは真面目な企業向けではありません | |
| 開発者はインフラストラクチャを理解し、エンジニアはコーディングします | |
| ITOpsチームは必要ありません。すべてがクラウドに移行するためです。 | |
| DevOpsを実装する際の主なことは、適切なツールを選択することであり、他には何も必要ありません | |
| 開発者向けのDevOps：すべてが可能になりました！ | |
私たちは、
その結果、2つのDevOpsモデルが形成されましたが、チームは今日これを遵守しています。 サポートエキスパートとDevSupportエキスパートの新しい役割が登場しました。これらの役割は、お互いのプロセスに同僚をより詳細に没入させることを目的としたチームで形成された一連のプラクティスを開発および運用します。 新しい合意が構築され、相互作用の主な問題が対処され、期待が双方に表明されています。
| 共有DevOps
「共通の目標は、速度と信頼性の両方です」 | 組み込みDevOps
「すべてのチームメンバーは製品中心です。」 |
| このモデルは優先事項であり、すべてのチームで必要です。 それぞれの側面で、Dev + Opsは1人の従業員（Support Expert + DevSupport Expert）で際立っています。
このモデルでは、チームが目標に焦点を合わせます。 チームメンバーはプロセスに最大限関与します（実行+変更）。 誰もが自分が共通の製品に取り組んでおり、その安定性と開発に単一の責任があることを理解しています。 | このモデルは、DevOpsチームの存在を意味します。DevOpsチームは、一般にE2E製品の開発とサポートを担当し、各メンバーは異なる役割を果たすことができます。
サポートエキスパートはSCRUMチームのメンバーであり、このチームのすべての活動に完全に専念しています。 このようなモデルは、チームがかなり安定した製品を開発し、運用作業の量が少ない場合、および製品所有者の側でそのようなニーズがある場合にも可能です。 |
内部会議で達成された結果、口コミ、プロの誇りについての話が彼らの仕事をしました-非常に迅速にすべてのチームがテスト、配送、組み立てを自動化しようとし始めました。
最初は、「正しい」テクノロジーを使用した比較的「シンプルな」ストーリーがありました。彼らは自分たちで対処しましたが、一部の箱入りモンスターでは、外部ベンダーを「引き離す」必要がありました。 すべてのエピソードで、能力の内側の中心と同僚の熱意が大きな役割を果たしました。彼らのおかげで、彼らは恐らく自動化に適合していなかった恐竜でもCI / CDを展開することができました。
暗黙の基準が登場しました。効果的なソリューションとして確立され、インフラストラクチャで合意されたものです。 そのような決定は、承認、予算、調達、そして最も重要なこととして、すでに内部の専門知識がなくても、チームで非常に迅速に展開できます。 ここから始まりました... ITの各内部会議で、すべてのスピーチで、DevOps、成果（誰も失敗について話すのが好きではない）についての言葉が発せられ、チームの「献身」の程度のメトリックの開発が始まりました。 6か月ごとのリリースで製品をサポートした私たちは、それを反映し、言い訳をしました。彼らを紹介したいと言いますが、特別な意味はなく、人件費は報われません。 動きの大きさとさまざまな経路と実践には、基準と知識の両方が必要でした。
私たちの大規模なチームには、数年にわたって社内トレーニングプログラム「ITアカデミー」がありました。 コースのセットと教育方法論自体は、数年にわたって多くの変革を遂げてきました;その結果、アカデミーは教育へのアプローチの観点から、哀れな名前しか持っていません。 連続的な変化の本質は、理論的知識の汲み上げから実践的な作業への移行です。 クールなコーチを雇い、トレーニングを通してすべてのチームを運営し、証明書を配って、何も重要なものではなく、実用的なソリューションも手に入らないようにしました。 アカデミーの再開は非常に実用的でした。チームは
DevOpsを実装する上で、いくつかの成功、そして一般的には失敗について話すことになぜそれほど誇りを持っているのでしょうか？ 要するに-企業だから。 次の出版物で、このトピックを明らかにしたいと思います。大規模な（ITの標準による）チームの体系的で大規模な変更。 朝食の戦略を食べる文化について話をする予定です。 自動テストソリューション、CI / CD、インフラストラクチャの自動作成と構成の自動化ソリューションの技術的な詳細についてお話したいと思います。これがなければ、DevOpsは単なる刺激的なストーリーになるからです。 DevOpsメトリクスへのアプローチを開発するのに多くの時間がかかりました-これは間違いなく話し合う価値があります。 最後に、おそらくさまざまな方法で、開発者、システム管理者、テクニカルサポートの専門家の目を通して、移動したパスがどのように見えるかを知ることは興味深いです。 一般的に、トピックは開発中であり、出版物をフォローし、コメントを残します。どのトピックがあなたにとってより興味深いかについては、最初にこれについてお話します。