DevOpsエンジニア

この領域について

中核となる能力

• 01継続的インテグレーション

  共有ブランチを、いつでもリリースできる状態に保つことです。変更ごとの素早いフィードバック、決定的であるがゆえに信頼される検査群、そして一週間分の乖離を溜めるのではなく一日に何度も統合できる程度に短いビルド時間です。

• 02リリースとデプロイの自動化

  戻り道が定義された、無人で反復可能なデプロイです。ローリング、ブルーグリーン、カナリアリリース、フィーチャーフラグによる段階的な公開、反映後の自動検証、そして仮定ではなく実際に試したロールバックです。

• 03Infrastructure as Code

  サーバー、ネットワーク、クラスタとその設定を、バージョン管理された定義として表現し、変更をレビュー可能で帰属可能にします。この規律の核心はツールよりも、手作業のほうが速い場面で、記録に残らない手作業を選ばないことにあります。

• 04アーティファクトの昇格と環境の同一性

  リリース対象のコミットごとに一度だけビルドし、その同じアーティファクトを先の環境へ昇格させ、正当に異なる要素はすべて実行時に与えます。次の環境のために作り直せば別のアーティファクトになり、それまでに検証したものは別物についての検証だったことになります。

• 05監視とアラート

  何を測るかを決め、リソース使用率ではなく利用者から見える影響を反映した閾値を置き、鳴るすべてが対応に値する程度にアラートの数を絞ります。オンコールの設計——ローテーション、エスカレーション、引き継ぎ——は、この作業の後続ではなく一部です。

• 06信頼性目標とエラーバジェット

  信頼性を願望ではなく明示的な目標として述べ、残っているバジェットで次の変更を機能にするか修復にするかを決めます。慎重さをめぐる議論を、エンジニアリングとプロダクトの双方が読める数値へ変換する仕組みです。

• 07デリバリー経路上のシークレット

  認証情報をリポジトリ、イメージ、ビルドログから遠ざけ、長期の鍵ではなく短命で権限の狭い認証情報をパイプラインに発行し、ローテーションを、インシデント中に初めて試みるものではなく日常の作業にします。

• 08ビルドとサプライチェーンの健全性

  依存関係の固定、何をどのコミットからビルドしたかを記録する来歴、イメージスキャン、そして脅威モデルが求めるなら署名です。広い権限を持つパイプラインは組織内で最も価値の高い標的の一つでありながら、最も守りが薄いことがよくあります。

• 09インシデント対応と学習

  役割と単一の連絡経路を定めてインシデントを進行させ、その後、責任追及を伴わない振り返りを行って、担当者の決まった具体的な変更を生み出します。「もっと注意しよう」で終わる振り返りは、原因を特定したのではなく願望を記録しただけです。

よくあるご質問

よくあるご質問

DevOpsエンジニアとプラットフォームエンジニアは何が違いますか

DevOpsエンジニアが扱うのは変更の流れです。コミットが本番へ至る経路と、そこから返るフィードバックであり、通常はデリバリーチームの内側か、その隣で働きます。プラットフォームエンジニアは、他のエンジニアに向けた社内プロダクトを作ります。セルフサービスの窓口と、その上を通る十分に支えられた経路であり、下に何があるかを理解せずに組織の他の部分が利用できるものです。違いは、対象読者と成果物です。DevOpsの仕事は、変更がどれだけ安全に、どれだけ頻繁に利用者へ届くかで評価され、プラットフォームの仕事は、他のエンジニアが誰にも尋ねずに必要なものを得られるかで評価されます。

DevOpsエンジニアとクラウドエンジニアはどう違いますか

クラウドエンジニアの担当分野はプロバイダー層です。アカウントとネットワークの構成、アイデンティティと権限、マネージドサービスの選定、リージョン障害時にもシステムを維持する仕組み、そして環境全体の運用費用です。DevOpsエンジニアの担当分野は、クラウドかどうかを問わず、既に存在するインフラの上で動くデリバリープロセスです。小さな組織では一人が両方を担うのが一般的ですが、環境が大きくなると分かれます。プロバイダーの深さとデリバリーの深さが、一つの職務に無理なく収まらなくなるからです。

DevOpsは職種ですか、それとも文化ですか

両方であり、その緊張は言葉の綾ではなく実在します。もともとの主張としては、責任の分け方を指します。二つの集団のあいだに壁を置くのではなく、同じ人がソフトウェアを作り、動かすということです。職種名としては通常、責任の共有を実務的に成り立たせる自動化を専門とするエンジニアを指します。責任の分け方を変えないまま肩書きだけを採用すると、壁は新しい場所に建て直され、その向こう側に一人が立つことになりがちです。

監視と可観測性は何が違いますか

監視は、誰かがあらかじめ問うと決めた問いに答えます。キューは伸びているか、エラー率は閾値を超えたか、ディスクは埋まりつつあるか。可観測性は、誰も予期しなかった問いを後から立てられるというシステムの性質で、通常はトレース、構造化イベント、そして事後に切り分けられる高カーディナリティの属性によって支えられます。監視は何かがおかしいことを教えます。可観測性が必要になるのは、原因が誰もダッシュボードを作らなかった条件の組み合わせである場合で、難しい障害の多くはそれに当てはまります。

DevOpsエンジニアはオンコールに入るべきですか

通常は入るべきですが、一人でというのは望ましくありません。呼び出しを一度も受けないエンジニアは、アラートを誠実に保つためのフィードバックを失い、やがてデプロイは快適でも運用は不快なシステムを作るようになります。逆に一人だけが受け続けると、その人が組織で唯一の「仕組みの記憶」になり、静かに膨らむ集中リスクになります。より健全なのは、サービスを作った人たちをそのローテーションに入れ、デリバリーの専門家が全員分を肩代わりするのではなく負荷を分かち合う形です。

この職種がチケットの待ち行列になると、なぜうまくいかないのですか

依頼が起きた理由をなくすことではなく、依頼を閉じることに最適化されてしまうからです。環境の申請、アクセスの申請、パイプラインの修正を一件ずつ処理している人には、それらを不要にする余地がなく、待ち行列は片付く速さより速く伸びます。この職種から成果を得ている組織は、繰り返される依頼を設計上の欠陥として扱います。それは、待ち行列をさばく手を止めて修正に充てる許可を、誰かに与えるということです。

DevOpsエンジニアは既存の開発チームとどのように働きますか

御社のデリバリープロセスの内側で働きます。御社のパイプライン、ランブック、変更管理、オンコール体制であり、優先順位付けと日々の作業の方向づけは御社のエンジニアが行います。プロダクトの意思決定、ロードマップ、アーキテクチャ、エンジニアリング標準は御社のものであり続けます。雇用主はTalent.IDです。雇用関係、従業員福利厚生、給与支払い、タレント管理、そして継続的な従業員関係は当社が担い、今後も担い続けます。