会議の再考

IT環境での会議への態度はあいまいです。会議の沸騰した雰囲気のなかには、水中の魚のように感じる人もいれば、仕事にとって価値のあるものや新しいことを聞かないために、より迷惑な人もいます。



それにもかかわらず、会議は有用であり、会議に参加することで知識を交換し、業界がどのような呼吸をしており、どの方向に進んでいるかを知ることができます。 また、会議が別の都市や国で開催される場合、これは世界を見る絶好の機会でもあります。 主なことは、参加が雇用主が後援する「アカデミックツーリズム」にならないことです。



以前の記事でプロセスの 歴史と文化についてお話ししましたが、今日の私の話は、1回の旅行で世界観を変えることができるか、少なくとも先駆者DevOpsの魂に跡を残すことができるかについてです。

道を行く

旅行の時点でアプリケーション開発者として、プロジェクトでDevOpsプラクティスを試験的に行った経験があり、どのプロセスが適切に構築され、どのプロセスを改善したいかを理解しました。



確かに、旅行から数ヶ月が経過したときに私が出版することにした理由をたずねます。以下の物語は、ミュンヘンでの観光冒険や小旅行に関するものではなく、最終結果でした。 落ち着いてテストするには時間がかかります。







空港、ミュンヘン、会議



ミュンヘンはドイツのITの首都です。これは、多数のIT企業が都市に集中しているためです。 市は沈黙で迎えられ、45を超えるレポートが発表されたプログラムで予定されているDevOpsCon 2017カンファレンスは、運動のリーダーとのライブコミュニケーションに対する楽しい期待を刺激しました。

初日

会議への私の参加の最初の日は、ラッセル・マイルズが「ストレスによるソフトウェア開発システムの改善」というテーマで開幕しました。 このスピーチは、「開発者はおもちゃですが、実際の開発ではすべてが少し複雑である」という考えに支配されていた、懐疑的なエンジニアの集まりに対する一種の挨拶でした。



非標準的なアプローチのカリスマ的なラッセルは、ギターを弾き、歌を歌い、情報を巧みに提示し、プレゼンテーションに部分的にユーモラスな論文を挿入することで懐疑論者を引き付けることができました。そして、予期しない問題や重大なエラーを受け取ることなく、アプリケーションを混乱状態で実装します。 ユートピアですが、私はそれが本当に好きでした。







ラッセルマイルズの彼のパフォーマンスの1つで、ネットワークを破る



ホール間を移動しながら、KubernetesとOpenShiftのマイクロサービスプラットフォームであるfabric8に取り組んでいるRed HatソフトウェアエンジニアであるRoland Hussのスピーチに長引きました。 彼のスピーチのテーマは、「クラウドネイティブになる：クジラの時代のJava開発」でした。 kubernetesを使用した従来のJava開発からマイクロサービスへの移行を、痛みを軽減する、または痛みを伴わないものにする興味深いアプローチをいくつか実装しました。 Rolandは、環境を作成するために選択された主なツールについて説明しました：docker、kubernetes、fabric8、すべてが相互にどのように相互作用するか、またミニクラスターを組み立ててマイクロサービスの操作とインフラストラクチャの作成を練習する方法についても説明しました。 プレゼンテーションは楽しいものでした。最初に彼は基本について話し、それから私たちの目の前で彼は簡単なアプリケーションを書き、ドッカー画像を作成し、環境をセットアップし、書かれたアプリケーションをデプロイしました。











アンドリュー・ノイバウアーとトーマス・ユーベルのスピーチから、「DevOps嫌悪環境でのDevOps戦略の実装」というテーマで講演した要約をいくつか紹介します。 私にとって、これらはシンプルですが、実装とDevOpsの問題を理解して認識するための重要なポイントです。



•全員およびすべての問題を解決する人物開発者を隔離または雇用する試み。

•すべておよびすべてを自動化する欲求。

•自動化のみを希望する。

•運用の能力を開発に移し、最初の能力を放棄する試み



スピーカーが発言する論文は私にとって非常に身近なものです。DevOpsは、まず第一に、異なる考え方であり、誰もが慣れ親しんでおり、小さな反復増分による短いフィードバックサイクルであり、「アジャイル」と呼ばれる大きな旅の次の論理的ステップでもあります。 すべて本質的に。







会議では、Atlassian、Appdynamics、Cyber​​arkなどの企業の多くのスタンドがありました。 それらのほとんどは、プラットフォームの作成、インフラストラクチャの編成、ネットワークの監視などのためのサービスとツールを提供しますが、より効率的な開発への変換と移行を支援する企業の代表者がいます。 Appdynamicsの開発者たち、つまり一連のアプリケーションを監視するシステムを実証してくれた人たちに興味がありました。 開発者が考慮しなかったアプリケーションのネガティブなケースを再現し、リクエストが通過したノード、処理にかかった時間、NullPointerExceptionが発生したクラスのコード行を追跡することができました。 非常に便利なもの！ 私の仕事では、欠陥検出タスクに直面しました。同じシナリオで、複数のチームが一連の画面フォームを開発できます。 そうすれば、そのようなシステムは私が監視するのに非常に役立ちます。







AppDynamicsの同僚



それとは別に、アトラシアンの製品は世界中の多くの大規模な顧客に使用されています。 私の練習では、ConfluenceとJiraは、チームの作業の同期を支援します。 これは単一の情報フィールドであり、作業、参加者、製品のルールと技術に関する知識ベース全体が保存されます。 このプラットフォームを使用して、導入された変更について議論し、アイデアを収集し、ニュースを公開します。



Confluenceには、DevOpsプロセスで非常に役立つツールのセットがあります。

1. プロジェクトのポスターを使用すると、「木の後ろの森を見る」ことができます。言い換えると、すべてのグローバルデザインに対して全体的かつ明確なプレゼンテーションを行うことができます。
2. プロジェクトのロードマップを作成し、ステータスと期限を追跡することができる計画ツール。
3. 遡及およびインシデント分析用のページ。
4. 特にパイロットや実験に関連する監視機能。
5. 多数のウィキ、ニュース、ブログ機能。

Christian Kochの「エンタープライズでの展開パイプライン」のパフォーマンスは、大企業で働く人々にとって特に役立ちました。 クリスチャンは、大企業が産業環境への新機能の提供を加速しようとするときに直面する主な問題を強調し、目標を達成する方法を示しました。 主な方法の1つは、テスト、アセンブリ、分析など、かなり高度な自動化が行われる作業環境を作成することです。 これにより、手作業に時間を浪費することなく、同時にバグまたは動作不能の構成を持つアセンブリを「アセンブリラインから削除」できます。 したがって、各企業が決定できるのは、作業アセンブリの迅速な配信を保証すると同時に、何も破損させない独自のツールセットのみです。







これは、クリスチャンがリリースの頻度をスピードアップする抽象的なツールのセットをどのように見ているかです

ドリンク、トーク、カジノ

すべての会議の重要な価値はネットワーキングです。 私はこの機会に、長い間考えてきたいくつかのポイントを明確にしました。 たとえば、自動化に長年携わっており、柔軟な方法論に取り組んでいる企業の代表者が、「DevOps」または「アジャイル」であると安全に言うことができるかどうかを調べるには？ 予想どおり、私の対話者の誰もあえてそう言うことはありませんでした。 どこにでも「buts」または「ifs」があり、何人かは彼らがどれだけdevopsとアジャイルであるかを測定する方法だけを考えていると言いました。 夜の残りの時間では、最適化、自動化、および「エンジニアリングに常識を適用する」他の側面について話しました。 これは、DevOpsとアジャイルが何であるかを理解しようとしていたときに、対話者から繰り返し聞いてきた組み合わせです。 しかし、私はdevopsとビール発酵の類似性を引き出したエンジニアに特に驚きました。



これらのまったく関係のないプロセスに共通点があると思いますか？



ちなみに、アジャイルとdevopsのトピックは関連性があり、それはOvidiu Piticによって続けられました-Cognizantでのヨーロッパのアジャイルプラクティスの長である彼のスピーチ「Fueling Digital Transformation with DevOps」。



私はこのプレゼンテーションが他の人よりも好きだったことを認めます：会社で、小さなものから大きなものまで、深刻な決定を下すとき、各従業員がアジャイルの正直で基本的な原則に導かれたとき、それは印象的です。 アジャイルの「崇拝」や「高揚」のようには見えず、これらのルールや原則を「受け入れ」ている可能性が高く、誰もが彼に従う理由を決定しています。

二日目

最初の熱意が少し落ち着いたとき、急いで考え、新しいアイデアを味わい、情報を受け取りたいという欲求がありました。 この点で、トピック「プラットフォームエンジニアリングは新しいOpsですか？」に関するPhilipp Garbeのレポートの形式は非常に成功しました。



彼はスピーチを引用で始めました。







Philippは、彼らが最初に別々の開発チームとテストチームから離れてから、DevOpsエンジニアを見つけ、どのような問題に遭遇し、アプリケーションの開発と運用の両方を完全に担当するエンジニアリングチームの組織にどのようにやってきたのかを話しました。 私が理解したように、スピーチの主なメッセージは、プラットフォームと製品という2種類のエンジニアリングチームの割り当てです。 前者は機能的で信頼性の高い環境を提供するため、後者はユーザーに新しい機能を迅速かつ安全に提供し、構造化されたフィードバックを受け取ることができます。 特に、アプリケーションが複雑なソフトウェア全体を意味し、システム環境の複雑さが非常に高い場合、このアプローチは理にかなっているように思えます。



オランダのScala、PHPのJavaコンサルタントであるMichiel Rookによるレポート「データベーススキーマの移行とゼロダウンタイム」は、私にとって少し退屈でした。 講演者は熱心に、そして驚いた聴衆の前で、データベースを使用しなければデータベースの移行は簡単であるという推測を確認しました。 以下に示すデータベース更新スキームを使用していないため、このプレゼンテーションは巨大な発見ではありませんでした。







Michielは、データベースの移行中のダウンタイムを削減するために使用できるいくつかのルールについて説明しました。 たとえば、ロードバランサーを使用して、更新プログラムをインストールするためのアプリケーションがインストールされているノードの1つを無効にできます。







彼はまた、データベースでの作業を容易にし、エラーを減らすために、次のようにするといいだろうと述べました。



1）データベースの移行とソフトウェアの展開の間の「接続の切断」。

2）下位互換性を維持し、インタラクションコントラクトのみを拡張します。

3）破壊的な変更を放棄します。

4）データの操作時に機能切り替えを使用します。 たとえば、新しいテーブルフィールドに置き換えられた古いテーブルフィールドを削除します。



まあ、常に学ぶべきことがあります。



しかし、アトラシアンのトニー・グラウトの「DevOpsチームと将来の未来」に関するパフォーマンスは楽しかったです。 スピーチの中で、彼は「オープン性」の原則がどのようにチームが目標を達成するのに役立ち、ミスや詳細の欠落を避けることに焦点を当てました。 彼は、チームが意思決定、実験、試行、学習を行う方法、およびそのようなアプローチがチームのリターンを向上させる方法を示しました。 また、チームと協力する大企業の問題についても説明しました。セキュリティの制限のためにリモートで作業できないこと、異なる部門間の協力の文化がないためにチームの開発が遅いことです。 トニーは、効果的なチームインタラクションのための膨大な数の技術的ユーティリティがあるため、今日、従業員のリモートワークおよびチーム間トレーニングの組織、つまり「協力の文化」の作成に制限がないと確信しています。



アプローチの主な原則：

1. 実験。これにより、提供される機能の品質が向上します。
2. 将来の品質に投資し、可能な限りコンベアを自動化して、インフラストラクチャのスループットを最大化します。
3. 定期的に局所的な問題を解決し、顧客への新機能の提供をスピードアップします。

話の終わりに向かって、トニーは私にインスピレーションを与えるフレーズを発声しました：「あなたが求める変化になりなさい。」

乾燥残留物中

当初、DevOpsは自動化、スクリプトに関するものだと思っていました。 私が後で学び理解したように、かなり広範囲に渡る誤解は、プロセスと環境をさらに深く掘り下げます。DevOpsは、特定の技術的な倉庫だけでなく心理的な倉庫も意味し、柔軟な開発方法論と密接に関連しています。 この会議に参加することで、私の頭の中の知識を理解し、構築して全体像をつかむことができました。



事例、洞察、ネットワーキングは、探究心を刺激し、おそらく内部哲学者を刺激することさえあります。DevOpsは、ビジネスや利害関係者から実装者まで、各参加者の考え方です。 特定の種類のエンジニア、マネージャー、トランスフォーマーを雇って、それを会社に持ち込むことはできません。 Devopsはアジャイルと連携しています。 これは、あなたが長く、一生懸命に実験、植え付け、実験するために必要なものです。 考え方は、ソフトウェア開発の観点だけでなく、顧客とのやり取り、フィードバックの受け取り、指標の取得の観点からも変更する必要があります。



もちろん、エンジニアリングカルチャーが必要です。たまに欠陥や欠陥を見つけて修復する人もいれば、新しい機能を生み出す人もいますが、メソッドが最適に書かれているか、テストに合格したときにネガティブケースを正しく処理するかについて心配することはありません。小さな反復サイクルは考慮できません。 自動化を忘れないでください。自動化により、新しい機能を本番環境に導入する時間が大幅に短縮されます。これはおそらく、今日の多くの企業の弱点の1つです。



すばらしい本「The Phoenix Project：A Novel About IT、DevOps、Helping Your Business Win」では、3方向アプローチについて説明しています。 最初の方法では、個々のコンポーネントではなく、システム全体のパフォーマンスに焦点を合わせます。 2番目のパスに従うことは、システムのすべての顧客がフィードバックを聞いて理解し、正しく応答できるようにする短いフィードバックサイクルを構築することを意味します。 3番目の方法は、実験の文化を作り、スキルを磨くことです。 何か新しいことに挑戦するとき、それは特定のリスクと失敗をとる必要がありますが、それは私たちが成長し、より良くなることを可能にします。そして、次に不愉快な状況にいるとき、私たちはそれから抜け出す方法を確実に知っています。



これらの3つの原則はDevOpsの文化を最もよく表しているように思えますが、私たち全員が努力していますが、銀行システムの一部の原則、現在の組織、および一部の人々の世界観は、これらの原則を適切な範囲で従うことを許可していません。 実際、DevOpsは比較的新しい方向であると思います。そのため、人々は懐疑的であり、この方法論を適用しようとすると、答えよりも質問の方が多い場合があります。



私は本当に「柔軟に」ビジネスにアプローチしたコグニザントのアプローチが好きですが、同時に「品質」を失いませんでした：彼らのためのDevOpsは目標そのものではなく、特定のタスクを解決するためのツールでさえありませんユーザーが常に最高の製品を開発して提供できるようにします。



Devopsは、トレーニングと実験の独特な実践であり、新しいものがいつでも歓迎されます。 どこにもエラーはありませんが、この場合、間違いは前進するものであり、怖がらせたり、士気を低下させたりするべきではありません。 会議の後、私はアプローチを90度に変えました。なぜなら、会社の変革、devopの導入または柔軟な開発方法論への切り替えなど、開発チームから上級管理職へのプロセスのすべての参加者の参加が必要だと確信していたからです。 人々は仕事の中で何かを変えたり変えたりしたくないので、これが問題のほとんどが生じる場所です。 チームとして、私は他の参加者が私たちのプロセス、他のチームやブース管理者とどのように対話するかに反応するのをより頻繁に聞き始めました。 理想的には、横断的なチームのようなものを見て、参加者が一緒に問題の解決策を見つけ、経験を共有し、定期的にお互いにアイデアを出し合うことを望んでいますが、これはまったく別の話です。



また、会議に行くことや、仕事にもっと生産的にオフィスで集中することも必要だと思いますか？