collaboration devops
DevOpsでのコラボレーション：
DevOpsでの配信の小さな増分 以前のチュートリアルで詳細に説明されました。
DevOpsの重要なマントラはコラボレーションであるため、DevOpsという言葉が登場しました。
読み飛ばし=> 詳細なDevOpsチュートリアル
コラボレーションとは、プログラムの問題に対処するために1つのチームとして結集することです。これにより、プログラムの目標を達成できず、顧客の焦点を念頭に置き、責任を問われることなく、できるだけ早く問題として所有することで問題を解決できます。
コラボレーションでは、全員がお互いに話し合い、顔を合わせ、会議やディスカッションに参加し、お互いのタスクや依存関係を理解し、仕事の透明性を保ち、問題を防ぐために積極的に取り組むことを学びます。
ビデオ パート2ブロック5：コラボレーション –15分36秒
トランスクリプト：
コラボレーションという用語はDevOpsで何度も繰り返され、Devopsのマントラはコラボレーションです。それでは、ソフトウェア開発とDevOpsのコンテキストで「コラボレーション」が実際に何を意味するのかを理解しましょう。
私によると、組織が言うとすぐに、DevOpsを実装します。自動的に、DevOpsの実践に付随するコラボレーションの考え方が始まり、すべての人の心に集中し、コラボレーションに注意を向けるようになり、コラボレーションが必要だと感じ始めます。 。それがコラボレーションの魔法です。
そのため、プロジェクトの最初からDevOpsコラボレーションを開始することは、組織とチームにとって非常に重要です。つまり、プログラムのチームメンバーです。
DevがOpsとコラボレーションし、opsがdevチームとコラボレーションしているのを見て、DevOpsのコンテキストで実際にコラボレーションすることの意味を理解できるようにしたいくつかの例を説明します。
これはインスタンス1の表現です。
インストールスクリプトまたは構成スクリプトに不明な問題があり、運用チームが特定の地域のクラスターの特定のセットアップにソフトウェアをインストールする際に課題を見つけていたという事例がありました。
それはいくつかの未知のエラーを投げていて、開発環境では決して発生しなかった純粋な本番の問題であり、運用チームはそれがセットアップに関連するものであると考えて自分たちで解決するのに本当に多くの努力を費やしました、そして彼らは解決する必要がありますそれは、かなり長い間解決されませんでした。
その後すぐに、開発チームは支援を求められることなく提案しました。タイムゾーンは異なりますが、本番サイトを管理していました。一般的に、本番へのアクセスはすべての人に与えられるわけではなく、Opsはエラーを共有するだけです。チームがデバッグ目的で必要とする詳細またはその他の情報。
しかし、この状況では、開発チームのメンバーの1人にアクセスを許可する必要があります。このメンバーは、ライブで問題の分析に数時間を費やし、すぐに回避策を提供したため、問題は迅速に解決されました。
これは、開発チームが自発的に問題を所有し、運用チームが問題を解決するのを支援したコラボレーションのインスタンスです。これはコラボレーションの純粋な例です。
同様に、別の例として、私が描いたそれを図式的に示しましょう。もう1つの例は、特定のサイトで数日間ソフトウェアをアップグレードした後、問題なく動作していたことです。突然、アプリケーションのパフォーマンスが低下し始めました。
この減速により、エンドユーザーは深刻なトランザクション損失に直面し始めました。多くの苦情の電話がCSRに届き始めました。つまり、カスタマーサービスの担当者は、この問題についてチームのフォローアップを開始しました。
この場合、開発チームと運用チームの両方がすぐに集まり、運用チームから開発チームに提供された情報とテレメトリの詳細を使用して、問題をデバッグし、負荷分散の側面に問題があったことを特定できました。したがって、パフォーマンスは遅かった。
そのため、両方のチームが協力して問題を修正し、数時間以内に正常に戻しました。そのため、ここでは、DevとOpsの両方が前に出て、問題を解決するために協力しました。DevがOpsの問題を言って、OpsがDevの問題であると考え、開発チームがそれを調べて修正する必要があるのではありません。
これは、エンドユーザーが苦しんでいる問題と問題のニーズを念頭に置いて、誰の問題であるか、または誰の問題であるかを見つけるのに時間を浪費するかに関係なく、非難ゲームをプレイする代わりに、誰もが問題を所有するコラボレーションの明確な例です。間もなく修正される予定です。
したがって、ここでも、問題は本番環境だけでなく、日常の問題、設計の問題、アーキテクチャの問題、さらには単純な社内ソフトウェア開発の問題でもかまいません。ツールの問題。
プログラムに関連する問題、またはチームが顧客に損害を与えている、またはプログラムの速度を低下させていることがわかっている問題は、開発の問題、運用の問題、またはテストの問題であるという問題を切り分けるのではなく、すべての人が所有する必要があります。できるだけ早く対処できるように貢献するのがコラボレーションです。
したがって、DevOpsコンテキストでのコラボレーションとは、開発と運用が連携し、お客様の焦点を念頭に置いて、問題をできるだけ早く解決するために連携することです。
技術者の面接の質問と回答をサポートします
コラボレーションは、特にエンドユーザーの利益のために本番環境で発生する問題を解決するために、ライブで何が起こっているかを所有するDevとOpsの両方であり、監視とロギング、およびパフォーマンスチェックが最優先されます。
または、簡単に言うと、チーム全体が常に協力して問題を解決し、プログラムの目標を達成し、顧客の焦点を念頭に置いていることがコラボレーションです。繰り返しますが、お客様の焦点を念頭に置いてプログラムの目標を達成するために、常に協力して問題を解決することがコラボレーションです。
次に、このコラボレーションをどのように開発し、何マイルも離れた場所にいるチーム間でいつコラボレーションを開始する必要があるのかという疑問が生じます。
明らかに、DevとOpsの両方が同じ場所に配置できないことはわかっています。運用チームは作業サイトまたはデータセンターに近く、開発者はソフトウェア開発センターに近い必要があります。では、どうすれば両方のチーム間の絶え間ないコラボレーションを実現できますか？
まず第一に、プロジェクトの最初からDevOpsコラボレーションを開始することは、組織とチームにとって非常に重要です。ここで意味するチームは、プログラムのチームメンバーです。
次のいくつかのことを実践することは、チーム間のギャップを埋め、仮想チームの制約を克服するのに役立ち、コラボレーションを実現するのに役立ちます。
それでは、コラボレーションの実現に役立つプラクティスを見てみましょう。
運用チームの関連するすべての会議とディスカッションに開発を関与させ、その逆も同様です。
これは、それらをまとめるだけでなく、それぞれの作業領域、日々の問題、および作業が互いにどのように影響しているのか、そして後で問題を回避するためにそれぞれが注意しなければならない重要なことを理解するのにも役立ちます。したがって、彼らを近づけ、毎回お互いに快適な話し合いを開始します。
DevOpsプラクティスが導入される前は、開発チームはソフトウェアをオペレーションに提供することについて何も気にかけていませんでした。インフラストラクチャ、構成、サーバーセットアップ、ネットワーク構成、ライブパフォーマンスの監視などについて、彼らが無知であるか、決して気にしないことを知っています。
彼らは、これらすべての活動は運用チームの責任であり、開発チームはそれについて知ることはなかったと考えていました。以前は、開発チームへの配信は運用チームのみへの配信を意味していましたが、DevOpsの実践では、配信は運用だけでなく本番への配信を意味します。
同様に、opsは、開発チームが作成しているコードを気にすることはありませんでした。ソフトウェアのインストール、機能、または本番環境でのパフォーマンスの問題で直面した問題は、単に開発チームにお金を渡して、修正して返送するように依頼するために使用されていました。
したがって、お互いの仕事を知り、彼らのタスクを理解し、サイクル全体でお互いの問題を所有することは、チームが問題を迅速に解決するのに役立ちます。
彼らは問題がどこにあるのか、プログラムで何が起こっているのか、そして何が本番環境で問題を引き起こしているのかを知っているので、それほど困難なく直接行って修正することができます。
したがって、コラボレーションとは、開発チームがインフラストラクチャと構成を理解する必要があり、運用チームがコード、品質、配信、およびタイムラインについて悩む必要があることを意味します。
相互の依存関係を理解することは、作業をスピードアップし、時間どおりに提供するのに役立ちます。
ソフトウェアのインストール時と同様に、運用チームは、インストールに関連する問題を解決するために開発チームに依存しています。同様に、開発チームのコーディングは、運用チームがコーディングプロセス中に注意を払うために提供する、ライブに存在する多くの前提条件に依存します。
別の 例 テストチームは、テスト用の本番環境からのサンプルライブデータを提供するために運用チームに依存しています。開発環境などで設定する環境構成の詳細。
そのため、両方のチームが協力して相互の依存関係を理解し、タイムゾーンの要素を考慮して遅延を発生させることなくデータまたは情報を時間どおりに提供する必要があります。
チームがプログラムに関するすべてを理解し、誤解を避けるのに役立つソース管理やバージョン管理などのDevOpsプラクティスを採用することにより、透明性を維持します。
つまり、これは基本的にチーム内の透明性を維持することです。
チームメンバーは、個人や特定の情報に依存する必要はありません。クラスター内の特定のノードに設定されている構成を誰かが知りたい場合は、運用チームが目を覚ますのを待つ必要はありません。これらの詳細を提供するのではなく、バージョン管理ツールにアクセスしてこの情報を取得し、遅滞なくタスクを完了することができます。
特に他の人の間違いからお互いから学ぶことは、コラボレーションの最大の特徴です。他の誰かがすでに行ったこれらの間違いを繰り返さないようにするためです。
つまり、開発は運用から学ぶことであり、運用は開発から学ぶことであり、それが新しいテクノロジー、ツール、またはより単純でより良い方法で何かを行うことです。それらの両方が同じページにあり、したがって、それらは互いに学習することによって互いに協力します。
経験豊富なoracleplsqlインタビューの質問
運用は常に、開発チームが非常に遅く、時間どおりに提供できないと感じていました。現在、開発チームと日々やり取りしているため、遅延の原因を理解しています。要件、設計の問題、コーディングの問題、またはその他のツールの問題。
彼らでさえ、改善するための貴重な提案を売り込み、提供しています。
また、本番サイトまたは開発サイトのいずれかから問題が発生した場合、DevOpsは、誰またはどのチームがこの問題を発生させたかを調べるよりも、最初に問題を修正する文化を導入します。そのため、誰が問題の原因を見つけるのに時間を無駄にするのではなく、誰もが問題の修正に集中しようとします。
ですから、それぞれの問題を自分の問題だと非難して考えるのをやめ、一緒に解決して問題をサポートするために前進し、問題の間にお互いをサポートすることは再びコラボレーションです。
だから、私は言うことができます、非難ゲームをやめなさい、非難ゲームはもう一度コラボレーションの特徴です。
誰もが同じ方向に共通して考え始め、同じ考え方と同じ側面と実践に取り組むことは、新しい機能が開発されるたびに、これをテストする方法、これを展開する方法、これを監視する方法、コラボレーションです。
したがって、一般的に考えると、チーム内はコラボレーションの特徴です。
今すぐ休憩して、次のビデオでコラボレーションについてもう少し理解しましょう。
前のチュートリアル | 次のチュートリアル