世界の古典が正確に定義しているように、組織は個人とグループの利益、インセンティブと制限、厳格な技術と革新、無条件の規律と自由な創造性、規範的な要件と非公式の取り組みが絡み合って共存する複雑な生物です。 組織が若いほど、その価値はあまり確立されません。 これは彼女の文化の変化を促進します。
エンジニアリングサブカルチャーを変更する実際の方法は、予想よりも困難でした。 開発者が恐れることなく自分の領域に忍び込むことができるように、開発者が製品の開発プロセス全体に責任を負い、管理者とメンテナンスの頭痛に悩まされるように、新しいテクノロジを開発者に興味を持たせる必要がありました。 私たちのチームには800人以上の開発者がいますが、そのほとんどは既に確立されたウォーターフォールの価値に根ざしており、ESFの目標とプロジェクトに必要な市場投入までの時間を提供していません。
MITのEd Scheine教授は、エンジニアと技術者が非常に独特であるという点で正しかった。 他のサブカルチャーは、彼らにとって理解不能で、いくぶんうるさいようです。 技術者は、技術の進歩と技術的な創造性の可能性に焦点を合わせました。 さらに、彼らは彼らをそこに引き付けるのではなく、彼らの世界から人々を生き残らせたいと思っています。 したがって、KPIの確立とエンドツーエンドの生産プロセスの自動化を通じてDevOpsを実装する簡単な方法は、私たちには適していませんでした。
トピックを研究した後、私たちは内部から文化を変えようとすることにしました。 開発チームに「すきから」伝道者を見つけ、彼らの例によってすべてが異なる可能性があることを示します。
「間違いをすることを恐れないでください。 時々、失敗するのは良いことです。 fireを壊すことを恐れてはいけない」（ S. Hanselman ）
簡単なメーリングリストから始めることにしました。 彼らは、実験、熊手、コーンを恐れない人々に応答するように頼みました。
800人以上の受信者の受信者データベースから、5人がパイロットへの参加申請を送信しました。 コンバージョンが1％未満の場合、少し混乱します。 レフ・グミリョフと彼の情熱的な民族形成の理論を思い出しました。情熱は、彼の人生、環境、現状を変えることを目的とした活動への抵抗できない内部の欲望です。 グミリョフの教えによると、ロシアは高いレベルの情熱を持った超態度であり、問題は-誰がどこへ行ったのか？ 私たちの準情熱を導いたのは何ですか？ 変更の恐怖？ 関与が少ない？ または、間違った通信方法を選択しただけですか？
マドリードで開催された夏のDevOpsカンファレンスを思い出しました。多くの外国人が、私たちがロシア出身であることを知り、Facebookに乗り込んで、他の国で働いているロシア人開発者を見せてくれました。 アクティブな情熱的な人々の大半はIT環境から移行しましたか？ どう思いますか？
「千人ほどの旅でさえ、最初の一歩から始まります」（ラオ・ツィ）
私たちはまだナッツェルシル少し情熱。 したがって、私たちの小さいながらも熱心なチームには、モスクワとイノポリス（タタールスタン）の経験豊富な開発者が含まれていました。 誰もが異なる経験と目標を持っていたので、彼らはすぐに役割を割り当てました。 そして、仕事は沸騰し始めました。
1か月後、開発チームは管理者および自動化とともに、パイプラインの最初のバージョンをセットアップし、他のチームへの複製を開始して結果を示しました。 コンソールを1.5時間手動でインストールする代わりに、10分でパイプラインを介して行われ、夜間に安定性がチェックされました。 アプリケーションのコンテキストを上げるための自動チェックがありました。 一般に、最適化作業は止まらず、誰もが製品をさらに改善したいと考えていました。 さらに、経営陣は、行われた作業に対するインセンティブを導入しました。
パイロットチームは簡単ではありませんでした。チーム内の設計タスクとDevOps開発を組み合わせる必要がありました。 結果に対する強力な本質的な動機は、プロセスの違いとコミュニケーションの障壁を克服するのに役立ちました。
後に、同盟関係者のグラデーションと彼らと協力する主なアプローチを推測しました。
- ダンノ（40％以上）
彼らは技術に慣れていないので、未知を恐れています。 そのような開発者とのコミュニケーションの結果は、その柔軟性と変化への意欲に大きく依存します。
若い「ダンノ」の割合が高いチームでは、変化のプロセスがより速く、より簡単になると期待されていました。 主な問題は地域への配布であるため、mitapを実行し、オンラインで同僚を含めました。
- 保守派（30％）
彼らはテクノロジーについては知っていますが、多くの「良い」理由で何かを変えたくありません：「私の責任範囲ではない」、「私はこれを20年間やっています」、「時間通りにコードを書くことがより重要です」など。
特に議論や例に公然と反対した人たちにとっては、彼らにとってはより困難でした。 この場合、上級人員の参加を得て合同会議や会話を行うために、管理砲を使用する必要がありました。
- 宗教狂信者（20％）
どのDevOpsが優れているか：コーシャと正統派のどちらですか？ 変更を開始したとき、サービスの開発は本格的で、一部はすでに運用中です。 ESFコア開発チームは、DevOpsを作成することができました。 実際、これは当時の自動化の最良の例でしたが、実践は開発者の立場でのみ行われました。 スケーリングには重大な変更と変更が必要でしたが、それは多くの動揺をもたらしました。
非常に賢く経験豊富な開発者に基づいているため、このグループに変更を導入することは非常に興味深いものでした。 最初のデモを実施した後、私たちは鮮やかな感情的な議論を行いました。パイプラインがどのように配置され、機能するかを示したとき、同僚はやり直したいと思いました。
- ストーリーテラー（10％未満）
残念ながら、ソフトウェアの品質に対する責任を受け入れない開発者のカテゴリーがあります。 たとえば、なぜ自動テストを作成する必要があるのでしょうか？ 「KPIだから」 したがって、彼らはこのタスクをより速く取り除くためにダミーのテストを書きます。 結果はストーリーテラーを含むすべての人に当てはまります。緊急モードでは、自動削除によって設定されたインストールがスタンドを台無しにし、他のチームはスタンドが復元されるのを待つことを余儀なくされるため、自分や近隣のプロジェクトの欠陥を修正する必要があります。
このカテゴリは、私たちにとって最も難しいことが判明しました。 それらの数が少なかったのは良いことです。 あなたは彼ら自身の過ちによってのみ彼らと働くことができます：彼らはテストのためにスタンドを破壊し、すべてのモジュールのために一日仕事をブロックしました-デブリーフィング。
反対意見を扱う際に、「指示を書くことにこれ以上労力を費やしませんか？」という質問としばしば対話を始めました。それは本当にうまくいった手がかりでした。
もちろん、DevOpsの作業がチームのバックログに含まれ、パイプライン構成マネージャーが各イニシアチブから割り当てられたとき、上記からのいくつかの要望がありました。 参加者は企業のSkypeを介して毎日のスタンドアップに接続されました。ESF開発チームはモスクワ、サンクトペテルブルク、ロストフ、ヴォロネジ、イノポリスなどの都市に分散しています。
「機会は現実を目覚めさせ、それを否定する以上にばかげたことはありません」（R. Musil）
単一の投稿は、私たちが使用する統一されたコミュニケーションとツールに専念します。 作業には、Confluence、SharePointを使用しました。そこでは、Ansibleスクリプトをセットアップするための一連のアクションを含むナレッジベースを作成し、コミュニケーションマトリックスとはるかに有用な情報をレイアウトしました。
スタンドアップに加えて、週に一度、パイプラインの作業に関するデモを開催しました。 時間が経つにつれて、バトンを編成しました。開発者は、パイプラインをセットアップした次のチームからデモを実施します。 DevOpsにチームを含めるプロセスはまだ停止していません;リレーアプローチにより、常に前任者が得たエクスペリエンスに何かを追加できます。
残念ながら、全員がパイロットのフィニッシュラインに到達したわけではありません。 快適なゾーンを離れて、あなたがしていることの価値を常に証明する必要性、二重の負荷と管理上の遅延（それらがない場合）はチームで損失なしに通過しませんでした。 今日、5人のESF実験者のうち3人だけがDevOpsの開発を続けており、残りはパイロットを辞め、チームの現在のタスクに取り組み続けています。 しかし、これら3人は現在、新しいエヴァンギリストに加わっています。
損失を回避できますか？ おそらくない。 しかし、もう少し慎重に行けば、先にブレークポイントが見えていただろう。 非生産的な活動を後押しするボーナスプログラムを導入しました。
その結果、プロセスの自動化が決定的なものではないという証拠を受け取りました。 800人以上の参加者全員が最後まで製品の責任を負うことで成功が達成され、これは特別なエンジニアリング文化の条件でのみ可能になります。 実施された変更のレベルを評価することは困難です;特定の指標の選択はまだ来ていません。 そして、DevOpsのどの指標が指標になると思いますか？