SRE オンボーディング

オンボーディングテンプレート

SRE のオンボーディングは主に2つの Issue テンプレートで処理されます。

  1. マシンセットアップ
  2. コンテキストの収集

これらは SRE の入社時にアサインされます。このテンプレートがシステムのさまざまな領域を案内し、簡単なタスクから始めて SRE と SRE マネージャー双方が各種アクセス問題を解決するのを助けます。

オンコールオンボーディングのための3番目の Issue テンプレートもあり、これは最初の2つが完了した後に実施され、開始日から少なくとも3ヶ月かかる可能性があります。

GitLab.com インフラストラクチャ管理

SREチームは GitLab.com インフラストラクチャの構成管理に Terraform と Chef を使用しています。

Terraform

Terraform の設定は現在3つの環境に分割されています。

ステージングと本番の両方に対して、これらの環境間のトポロジの一致を保つための 共有 terraform 設定 があります。インスタンスサイズ、フリートサイズ、その他の環境固有の設定は、ステージング、本番、ops 向けの変数ファイルに設定されています。

Terraform のステートはオブジェクトストレージに保持されており、マスターブランチは常にインフラストラクチャの現在の状態を表している必要があります。変更はCI経由でマージおよび適用されるべきです。

Chef

Chef は SRE インフラストラクチャ管理の重要な要素です。現在、OS のパッチ適用、システムレベルの設定適用、リリース用の omnibus パッケージのインストールに使用されています。新しい SRE にとって良い出発点となるいくつかの注目すべきクックブックを以下に示します。

  • cookbook-omnibus-gitlab: このクックブックは GitLab がインストールされているすべてのサーバーに gitlab.rb を作成する責任があります。この設定ファイルは omnibus パッケージによって使用されます。
  • gitlab-cookbooks: GitLab.com で使用されるクックブックのコレクションです。

リリース

リリース候補は週を通じて行われる自動デプロイを通じて GitLab.com にデプロイされます。GitLab.com でのリリースについての情報は リリースプロセス および release プロジェクトのドキュメント を参照してください。

GitLab.com のデプロイとパッチについては、以下のリリースドキュメントを参照してください。

情報の探し方

リポジトリ

以下のリポジトリは GitLab.com インフラストラクチャ管理に使用されています。これらのリポジトリの場所は、SREチームがプッシュ、Issue、MRに使用するリモートです。GitLab.com が利用できない場合に備えてミラーが設定されています。アセット、設定、インフラストラクチャ、リリース、パッチ管理に必要なリポジトリは https://ops.gitLab.net をリモートとして使用します。

  1. terraform: GitLab.com のステージング、本番、運用環境のすべての terraform 設定を保持するリポジトリです。GitLab.com 上に リポジトリミラー があります。

  2. chef クックブック: GitLab.com に使用されるクックブックのリポジトリです。フリートのランリストはロールで設定されています。これらのクックブックの ops.gitLab.com 上にリポジトリミラーがあります。

  3. chef: このリポジトリには GitLab.com インフラストラクチャのすべてのロールとノード属性が含まれています。また、クックブックバージョンのピン留めのための本番、ステージング、ops の環境設定も含まれています。

  4. runbooks: このリポジトリには GitLab.com のランブック、ハウツー、アラート定義が含まれています。このリポジトリで定義されたアラートは、マスターにマージされると監視インフラストラクチャに自動的に適用されます。詳細は アラートセクション を参照してください。ops.GitLab.net 上に リポジトリミラー があります。

ダッシュボード

以下のダッシュボードをブックマークして簡単にアクセスできるようにしておくと便利です。

  1. Grafana
  2. Google Cloud
  3. システムログ
  4. Fastly CDN

クラウドプロバイダー

  1. Google Cloud
  2. Amazon Web Services

監視ツール

  1. incident.io アラート
  2. Grafana パフォーマンス監視
  3. アラートダッシュボード

Issue トラッカー

以下の Issue トラッカーをブックマークして簡単にアクセスできるようにしておくと便利です。

  1. オンコール Issue
  2. 本番インシデント Issue
  3. 変更管理 Issue

YubiKey

SRE は YubiKey を使用するべきで、ラップトップに鍵を保存すべきではありません。プライマリキーを紛失した場合にアカウントからロックアウトされないよう、予備の YubiKey を持つことをお勧めします。

セットアップには yubikey ランブック に従ってください。

認証情報

以下は、上記または他のハンドブック箇所でカバーされていない、設定が必要な認証情報とアクセスの包括的なリストを意図しています。リストは最新でない場合があります。不足しているものがあれば追加してください。

  1. SSH キー - yubikey セットアップで提供されます

  2. GitLab.com アカウント

  3. GitLab.com 管理者アカウント

  4. dev.GitLab.org アカウント

  5. ops.GitLab.net アカウント

  6. Chef アクセス

  7. クラウドプロバイダー

    • Amazon Web Services
    • Azure
    • Digital Ocean
    • Google Cloud

Slack チャンネル

  • オンコール関連チャンネル:
    • production
    • incident-management
    • alerts
    • announcements
    • dev-escalation
    • feed_alerts-general
    • cloud-provider-alerts
  • インフラストラクチャチャンネル:
    • infrastructure-lounge
    • infra-read-feed
    • g_release_and_deploy
    • infra_capacity-planning
    • ansible
    • kubernetes
    • terraform

Zendesk

すべての SRE は Zendesk で「ライトエージェント」アカウントを登録するべきです。インシデントはしばしばカスタマーレポートから発生し、彼らの提出内容やサポートとのやり取りを確認することが有用です。また、トラブルシューティングのためにより多くの情報を収集できるよう、サポートエンジニア向けの内部メモを残すこともできます。

Time Off by Deel

計画的な休暇の通知と委任には Time Off by Deel を使用します。Slack との連携を設定する際は、/time-off-deel help コマンドを実行してから「Go to Home Tab」をクリックし、ドロップダウンで「Calendar Sync」を選択し、「Add Calendar」をクリックしてチームの共有 Google カレンダー（ID: [email protected]）を「Additional calendars to include?」として追加してください。

推奨ソフトウェアツール

プロダクションエンジニアとして Linux ワークステーションの利用が許可されています。以下のリストは主に macOS ツールで構成されています。お使いの Linux ディストロに合った Linux 相当品を見つける必要があります。

GitLab の他の部分と連携するための標準ツールに加えて、以下のツールは本番の問題を処理するうえで役立ちます。

必須ツール

  1. Homebrew
  2. SSH（適切に設定済み）
  3. chef、knife、berkshelf
  4. kubectl（brew install kubernetes-cli）

あると便利

  1. iTerm（brew install iterm2）または kitty（brew install kitty）（kitty は設定により多くの手間がかかるため上級ユーザー向けです）
  2. macOS はデフォルトで ~/.bashrc ファイルを読み込まないため、処理させたい場合はプロファイルファイルでソースする必要があります（手動で作成が必要な場合もあります）。プロファイルの代わりにrcファイルを作成する理由は、一部のツールがデフォルトでrcになっているためプロファイルを処理しないためです。実際にはさらに多くの違いがあります。詳しくは macOS での bash_profile と bashrc について を参照してください。
  3. macOS はデフォルトで bash 補完機能を持っていません。インストールするには brew install bash-completion を実行し、有効化するには echo "[ -f /usr/local/etc/bash_completion ] && . /usr/local/etc/bash_completion" >> ~/.bashrc を実行します。
  4. fzf はシェルでのファジー補完（例: 履歴検索やファイルパス）に使用されます（brew install fzf + echo "[ -f ~/.fzf.bash ] && source ~/.fzf.bash" >> ~/.bashrc）
  5. macOS のデフォルトの bash 履歴の長さは 500 です。保持するエントリ数を増やしてタイムスタンプを保存するには、.bashrc に以下を追加します。
export HISTFILESIZE=2000000
export HISTSIZE=1000000
export HISTTIMEFORMAT="%d/%m/%y %T "
  1. helm - 「Kubernetes パッケージマネージャー」（brew install kubernetes-helm）
  2. minikube（brew install minikube）および virtualbox（https://www.virtualbox.org/wiki/Downloads）
  3. GCP cli gcloud クイックスタート macOS
  4. Digital Ocean cli（brew install doctl）
  5. Azure cli（brew install azure-cli）
  6. AWS cli（pip3 install awscli --upgrade）
  7. Sublime、Textmate、MacVim、または neovim などのテキストエディタ
  8. watch（brew install watch）
  9. tmux/tmate（brew install tmux tmate）
  10. macdown などの Markdown エディタ（brew install macdown）
  11. BitBar と GitLab プラグイン
  12. gnu ユーティリティをインストールして Mac ユーティリティを置き換えるには –with-default-names オプションを使用します。
  13. gpg を使用する場合、パスワードが要求されます。パスワードの問い合わせはさまざまなツールで容易にできますが、かなり標準的で広くサポートされているのは pinentry-mac です（brew install pinentry-mac）。gpg エージェントにそれを使うよう伝えるには: echo 'pinentry-program /usr/local/bin/pinentry-mac' >> ~/.gnupg/gpg-agent.conf

Brew ファイル

サンプルの brew ファイルは Infrastructure プロジェクト にあります。

iOS アプリ

  1. Slack
  2. Zoom
  3. incident.io
  4. Working Copy（オプション）

リファレンス資料

エンジニアが復習する必要があるかもしれない関連リファレンス資料のリスト

  1. Chef
  2. Terraform ドキュメント または 入門ガイド
最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License