Content last updated 2026-05-01

SRE オンボーディング

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

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

これらは、SRE が業務を開始するときに割り当てられます。簡単なタスクから始めてシステムのさまざまな領域へとガイドし、SRE と SRE マネージャーの両方が各種アクセス関連の問題を解決していくのを助けます。

3 つ目の Issue テンプレートとしてオンコールオンボーディングがあります。最初の 2 つの完了後に着手するもので、開始日からおそらく少なくとも 3 か月程度を要します。

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

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

Terraform

Terraform 構成は現在、以下の 3 つの環境に分かれています:

staging と production の間でトポロジの一貫性を保つため、共有 terraform 設定が用意されています。インスタンスサイズ、フリート規模、その他の環境固有設定は、 staging、production、ops の変数ファイルで設定されます。

terraform の state はオブジェクトストレージで管理されており、master ブランチが常にインフラストラクチャの現在の状態を表すべきです。変更は CI を通じてマージおよび適用されるべきです。

Chef

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

cookbook-omnibus-gitlab: この cookbook は、GitLab がインストールされているすべてのサーバーで gitlab.rb を作成する役割を担います。この設定ファイルは omnibus パッケージで使用されます。
gitlab-cookbooks: GitLab.com で使用される cookbook のコレクションです。

リリース

リリース候補は、週を通して行われる自動デプロイメントによって GitLab.com にデプロイされます。GitLab.com におけるリリースの仕組みについては、リリースプロセスを参照し、 release プロジェクトのドキュメントもご覧ください。

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

どこに何があるか

リポジトリ

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

terraform: このリポジトリには、GitLab.com の staging、production、ops 環境のすべての terraform 構成が保管されています。 GitLab.com 側にはリポジトリミラーがあります。
chef cookbooks: これらは GitLab.com で使用される cookbook のリポジトリです。フリートの runlist は role で構成されています。これらの cookbook のリポジトリミラーが ops.gitLab.com にあります。
chef: このリポジトリには、GitLab.com インフラストラクチャのすべての role と node の属性が含まれます。 cookbook のバージョン固定のための production、staging、ops の環境設定もあります。
runbooks: このリポジトリには、 GitLab.com のランブック、ハウツー、アラート定義が含まれています。このリポジトリで定義されたアラートは、 master にマージされるとモニタリングインフラストラクチャに自動的に適用されます。詳細は alert セクションを参照してください。 ops.GitLab.net 上にリポジトリミラーがあります。

ダッシュボード

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

クラウドプロバイダー

モニタリングツール

incident.io アラート
Grafana パフォーマンスモニタリング
アラートダッシュボード

Issue トラッカー

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

Yubikey

SRE は YubiKey を使用し、ノートパソコンに鍵を置かないようにすべきです。プライマリキーを紛失したときにアカウントからロックアウトされないように、予備の YubiKey を用意することを推奨します。

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

クレデンシャル

以下は、上記または handbook の他の箇所でカバーされていない、設定する必要のあるクレデンシャルとアクセスの包括的なリストとなることを意図しています。このリストは最新ではない可能性があります。何か漏れている場合は、追加してください。

SSH キー - yubikey のセットアップで提供されます
GitLab.com アカウント
GitLab.com 管理者アカウント
dev.GitLab.org アカウント
ops.GitLab.net アカウント
Chef アクセス
クラウドプロバイダー
- Amazon Web Services
- Azure
- Digital Ocean
- Google Cloud

Slack チャンネル

オンコール関連のチャンネル:
- production
- incident-management
- alerts
- announcements
- dev-escalation
- feed_alerts-general
- cloud-provider-alerts
Infrastructure チャンネル:
- infrastructure_platforms
- infra-read-feed
- g_release_and_deploy
- infra_capacity-planning
- ansible
- kubernetes
- terraform

Zendesk

すべての SRE は ZenDesk で「Light Agent」アカウントに登録するべきです。インシデントはしばしば顧客レポートから発生するので、顧客の提出内容とサポートとのやり取りを確認できると便利です。また、サポートエンジニアがトラブルシューティング目的でより多くの情報を集められるように、内部メモを残すこともできます。

Time Off by Deel

私たちは Time Off by Deel を使って、計画された休暇の通知と委譲を行っています。Slack との連携を設定する際は、 /time-off-deel help コマンドを実行してから Go to Home Tab をクリックし、ドロップダウンで Calendar Sync を選択した後、Add Calendar を選んで、チームの共有 Google Calendar (ID: [email protected]) を “Additional calendars to include?” として追加することを忘れないでください。

推奨ソフトウェアツール

プロダクションエンジニアとして、私たちは Linux ワークステーションを利用できます。以下のリストはほとんどが macOS ツールで構成されています。お好みの Linux ディストリビューションに合わせて Linux 同等のものを見つける必要があります。

GitLab の他の部分とやり取りするための標準ツールに加えて、プロダクションの問題に取り組む際に役立つツールは以下のとおりです。

必須ツール

Homebrew
SSH、適切に設定済み
chef, knife, berkshelf
kubectl (brew install kubernetes-cli)

あると良いもの

iTerm (brew install iterm2) または kitty (brew install kitty) (ただし kitty は使用開始までに多くの設定が必要なため、より上級者向けです)
macOS はデフォルトでは ~/.bashrc ファイルを読み込まないので、それを処理させたい場合は、自分の profile ファイルでソースする必要があります（このファイルは手動で作成する必要がある場合があります）。すべてを profile に保持する代わりに rc ファイルを作成するのはなぜか？一部のツールはデフォルトで rc を使用するため、profile はまったく処理されません。実際にはもっと多くの違いがあります。macOS での bash_profile と bashrc についてを参照してください
macOS はデフォルトでは bash 補完機能を持たないので、インストールするには: brew install bash-completion を実行し、有効化するには: echo "[ -f /usr/local/etc/bash_completion ] && . /usr/local/etc/bash_completion" >> ~/.bashrc
fzf はシェルでのファジー補完（履歴検索やファイルパスなど）に使用します (brew install fzf + echo "[ -f ~/.fzf.bash ] && source ~/.fzf.bash" >> ~/.bashrc)
macOS では bash 履歴のデフォルト長は 500 です。保持されるエントリ数を拡大し、タイムスタンプを保存するには、たとえば以下を .bashrc に追加できます:

export HISTFILESIZE=2000000
export HISTSIZE=1000000
export HISTTIMEFORMAT="%d/%m/%y %T "

helm - “Kubernetes package manager” (brew install kubernetes-helm)
minikube (brew install minikube) と virtualbox (https://www.virtualbox.org/wiki/Downloads)
GCP cli gcloud quickstart macos
Digital Ocean cli (brew install doctl)
Azure cli (brew install azure-cli)
AWS cli (pip3 install awscli --upgrade)
Sublime、Textmate、MacVim、neovim などのテキストエディタ
watch (brew install watch)
tmux/tmate (brew install tmux tmate)
macdown (brew install macdown) などの markdown エディタ
BitBar と GitLab Plugin
GNU ユーティリティをインストールして mac ユーティリティを置き換えるには –with-default-names オプションを使います。
gpg を使う場合、パスワードを聞かれます。パスワードの問い合わせはさまざまなツールで容易にできますが、かなり標準的で広くサポートされているのが pinentry-mac です (brew install pinentry-mac)。gpg-agent にこれを使うよう伝えるには: echo 'pinentry-program /usr/local/bin/pinentry-mac' >> ~/.gnupg/gpg-agent.conf

Brew ファイル

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

iOS アプリ

参考資料

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

Chef
Terraform ドキュメントまたは入門ガイド

最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (c955a93f)

ページのソースコードを見る - ページの編集 - please contribute.