今週末、私はニューヨーカーのいくつかの問題に追いついていました。私のお気に入りのニューヨーカー作家のXNUMX人であるAtul Gawandeの記事が、テクノロジー企業とDevOpsについて多くのことを明らかにしていると私を驚かせました。 （これは、LogicMonitorの文化の一部である、さまざまな無関係のソースからのアイデアの例です。実際、昨日、チーフネットワークアーキテクトは、サポートエンジニアにログインを求められたときに、セキュリティと説明責任を改善するという素晴らしいアイデアを思いつきました。顧客のアカウントに–そしてこのアイデアは彼と私が充電している間に彼に起こりました ジーサスイータトレイル マウンテンバイクで。）
記事、 Atul Gawande：良いアイデアはどのように広まるのですか？ ：ニューヨーカーは、いくつかの優れたアイデア（麻酔など）がすぐに採用されたのに対し、他の価値のあるアイデア（消毒–細菌を医療処置から遠ざける）が採用されなかった理由についての調査です。 では、これはDevOpsやテクノロジー企業とどのように関係しているのでしょうか。
テクノロジー企業、または実際にはどの企業でも、課題のXNUMXつは、ベストプラクティスが実際に採用されていることを確認することです。 私たちは皆、非難すべきではないことを知っています、 なぜなぜ 障害と停止の根本原因を特定するための調査。 問題が再発した場合に確実に検出されるように監視を行うまでは、問題をクローズしたと見なすべきではないことは誰もが知っています。 NS DevOpsのベストプラクティス 秘密ではありません。 それらはほとんど常識です。
では、なぜそれらはすべての企業の標準ではないのでしょうか。 何年もの間（ほとんどの場合）DevOpsショップを務めてきたLogicMonitorでも、部門の枠を超えた展開計画がないなどの理由で、足りないことがあります。
同様に厄介な問題は、営業チーム間でのベストプラクティスの普及にあります。 自分の環境に飛び込んでLogicMonitorをセットアップしたい場合、営業担当者がデモを試みる必要があるのはなぜですか？ それでも、デモを通過する人々は、彼らの監視が何であるかに気づきます かもしれない、そして一般的にそうでないものよりも大きな成功を収めています。 営業担当者はこれを知っていますが、顧客をデモに誘導しようとしない方が簡単です。
Atulは、両方の問題の難しさは同じであると主張しています。望ましい変更には、結果の違いが見えない時点で動作を変更する必要があります（コーディング（またはセールスコール）のこの時点でOps（またはデモ）が関与しているかどうかは誰にもわかりません） ）この展開の成功は変わりますか？）、そして変更は退屈であり、現在の基準に反します。
処方箋（「これを行う！」）もインセンティブ（「これを行うと私たちはあなたに支払います！」）も規範の変更に役立つようには見えません。
代わりに、最善のアプローチは、メンターを使用して、人々の注意を彼らのやり方、ベストプラクティスと一致しない方法に呼びかけ、なぜ彼らが何に一致する方法で行動していないのかを友好的に話し合うことであるようです。彼らは最適であることを知っています。 これは、自己管理チームのアジャイルの概念とも非常によく一致しています。メンターとメンターは、問題やベストプラクティスについて話し合い、この状況で機能するように実装する方法を考え出します。 誰も何もするように指示されていません。 Atulによると、この成功した関係の鍵は、メンターが「素敵」であることです。 （その基準をSalesまたはDevOpsで見つけるのが難しくなるかどうかについてのコメントはありません。）
したがって、営業チームと開発チームおよびTechOpsチームでは、メンターを特定していることを確認してください。チームの現在の作業方法と、それがフィールドのベストプラクティスにどのように関連しているかについて客観的な見方をしてくれる人です。違いがある場合は、話し合いをやさしく案内します。 ベストプラクティスは、すべての状況で正しい道であるとは限りませんが、発散は、以前の規範への復帰だけでなく、意識的な決定である必要があります。