最近の出版物では、最新のソフトウェア組織におけるサイト信頼性エンジニアの台頭について検討しました。 しかし、SREと呼ばれることは一つのことですが、このポジションで成功するために何が必要かを知りたいです。
したがって、本当に成功したSREに共通する特性と習慣を研究することにしました。 ほとんどの開発および運用と同様に、一流の技術スキルが重要であることは明らかです。 SREの場合、これらの特定のスキルは、特定の組織がどのようにポジションを定義または適用するかに依存する場合があります。 QA）。 それにもかかわらず、研究中に判明したように、 開発と運用の専門家を成功させるもの、「素晴らしい」と「十分な」を区別するのは、しばしば技術的専門知識を補完する習慣と特性の組み合わせです。
以下に示す7つの習慣は、New Relicの従業員であるBeth Long（ソフトウェアエンジニア）とJason Qualman（サイト信頼性エンジニア）の詳細なインタビューから得られました。 見てみましょう：
習慣1：（はるかに）全体像のコンテキストで各変更を分析します
成功したソフトウェア開発者は、コードがビジネス全体にどのように役立つかを理解しています。 SREには、この特性の独自のバージョンがあります。 「日々の仕事だけでなく、全体像についても本当に考えている人が必要です。 成功したSREは、物事をより高いレベルで理解し説明することができます」とジェイソンは言います。 New Relicの内部では、「今日だけでなく、あらゆるリスクにおいて、起こりうるリスクとその将来への影響を常に分析している人々」のような人々を説明しています。 これは大規模なインフラストラクチャにとって何を意味しますか？
習慣2：分析において実用的で先見の明がある
最高のSREは実用的なアプローチを採用し、その作業がシステムまたはチームの残りの部分にどのように影響するかを評価します。 このアプローチにより、変更が「反対側に座っている人にどのように影響するかを理解せずに壁を越えて投げられる」可能性が最小限に抑えられます。
「スタック全体で非常に低いレベルの決定を下します。 時には彼らは上記の全員を傷つけることができます。 特定の問題を解決することが、途中で会う他のすべての人にどのように影響するかを理解する必要があります」とジェイソンは言います。
習慣3：何かが役に立たないときも動き続けたい
SREの実用的なアプローチの一部は、適切かもしれないが実際には効果的ではないプロセスと操作を破棄したいという欲求です。 Bethは、New Relicが信頼性のプラクティスを変更した例を思い出します。
「数年前、私たちは活発な成長の段階を経ており、これに関連する不安定さを防ぐために、Change Acceptance Board（CAB）プロセスを実装しました[変更の受け入れに関するアドバイス。 どうやら、それは変更諮問委員会を意味する- 約。 perev。 ] 。 これは、何かを壊して将来のインシデントを引き起こす変更から保護するために、実稼働環境でのリリース前にリリースを評価するのに役立つことを目的としていました。 皮肉なことに、リリースサイクルの速度が低下すると、より多くの変更が蓄積され始め、その効果は計画とは完全に反対になりました。 これらの大きな変更により、各リリースのリスクが増加しました。」
最終的に、CABプロセスはより頻繁で小規模なリリースを支持するようになり、より良い結果が得られました。
習慣4：すべての自動化機能を使用します
ハイエンドのSREは、ソフトウェアの迅速な提供能力を低下させることなく、すべての信頼性を高める方法という主要な困難にうまく対処します。 ソリューションはほとんどの場合自動化です。 SREは、新しい自動化方法またはプロセス変更を使用して、手動での対話が実行される労働集約的なタスク、バグなどの解決策を積極的に検索する必要があります。
「この立場の重要な要素は、非効率的で時間のかかるタスクを考え、それらを可能な限り迅速に廃止することです。 手動で実行されるタスクのソリューションを延期する代わりに、「今すぐ自動化する時間を見つけて、誰もがこの苦痛な活動をしなくて済むようにします」と言います」とジェイソンは説明します。
自動化へのこだわりはNew Relicに限ったことではありません。たとえば、 DevOpsハンドブックには、手動プロセスを受け入れることの逆説的な効果について説明する章全体があります。 SREの職務記述書では、「自動化」とそのさまざまな表現が他の言葉よりも一般的です。 建設管理ソフトウェア会社であるロサンゼルスのプロコアテクノロジーズによる最近の SREの欠員の説明には、「自動化、自動化、自動化、そして...自動化」という2番目の段落があります。 （元の公開から4日しか経過していませんが、言及された空席は既に閉鎖されていますが、ここでは、他社によるSRE義務の説明で「自動化」の他の多くの例を見つけることができます。
習慣5：必要なことを行うように組織を説得することができます
特定の自動化タスクまたは他のSREイニシアチブを支持する自信は、最高のSREを定義する別の属性です。 自分の立場、あるプロセスを自動化することが重要な理由、または作業の別の部分を守る必要があります。 また、ソフトウェアの分野で働いている多くの伝統的な組織の文化と作業速度との衝突を引き起こす可能性があるため、それは難しい場合があります。
ポートランドニューレリックラリー
優れたSREは、エンジニアリングに特化したバージョンのセルフヘルプクラシックの「友だちに勝ち、人々に影響を与える方法」で生きています。 簡単に言えば、彼らの仕事には、最初は望まないことを他の人に説得する必要があります。たとえば、ソフトウェアエンジニアは製品の機能ではなく、製品を複数の製品にスケーリングする際に発生する問題来年。
最高のSREは、短期的には困難であることが判明したとしても、特定のプロセスまたはプロジェクトを自動化することの長期的なメリットを同僚に販売できる効果的な売り手である必要があります。 結果は？ 「あなたは自分の立場を擁護し、停止するか否かを言うことができなければなりません。私たちは今それを本当にする必要があります。これは一部の組織では難しいかもしれません」とベスは説明します。
習慣6：新しいツールとアプローチでスキルを伸ばします。
SREの概念はまだ新しいため、以前は多くのSREが他の役職を務めてきました。 開発者の経験があるSREもあれば、従来の運用方法を持っているSREもあります。 ジェイソンとベスは、SREの役割を特定の過去の経験に限定しない雇用マネージャーが最も効果的であることに注目しています。 たとえば、従来のQAエンジニアは、SREの職務について適切なトレーニングを受けることもできます。
過去に関係なく、SREのポジションがあなたの快適ゾーンを離れ、新しいスキルを開発することを強制する可能性があります。 たとえば、運用分野の専門家は、プログラミング言語を1つまたは3つ勉強することが有用だと感じるかもしれません。開発経験のある人は、過去に行っていた操作や操作の難しさについて、もっと徹底的に考え、学びたいと思うでしょう。 最高のSREは、トレーニングとスキル開発のこのパスを取ります。
習慣7：プロセスを信頼する
SREを成功させるための指針となる哲学がある場合、それは次のように表現できます。実際、すべての故障を防ぐ聖杯を追求しません。 これはめったに機能しません。 その代わりに、全体像を確認し、自動化を実装し、健全なパターンを刺激し、新しいスキルとツールを学び、あなたが行うすべての信頼性を向上させるために、疲れることなく働きます。 完璧を達成することはできませんが、すべてをより良くしたいという絶え間ない欲求は従うべき方法です。
休暇中のNew Relic Americanエンジニア
PSすべての会社の写真はGlassdoorから撮影されています。