Wantedly Engineering Handbook
  • Wantedly Engineering Handbook
  • まえがき
  • 第一部:開発チームへの案内
    • 技術とアーキテクチャ
    • プロダクト概要(未執筆)
    • 開発チームの構造
    • コミュニケーションの全体
    • ドキュメンテーション(未執筆)
    • カレンダー
    • 障害対応の心構え
    • 効率的な社内知識の調べ方
    • 外部発信(執筆中)
  • 第二部:技術領域への案内
    • Apps
      • アプリを提供するプラットフォーム
      • デザインシステム入門
      • Web アプリのアーキテクチャ
      • プロダクトデザイナーと上手に協働するための心得
      • Web アプリのデザインシステムライブラリ
      • Web アプリ共通ライブラリ "React Shared Component" の紹介
      • モバイルアプリのアーキテクチャ
      • モバイルアプリのデザインシステムライブラリ(未執筆)
    • The System
      • protobuf スキーマと gRPC 通信
      • 実践: gRPC in Ruby
      • 実践: gRPC in Go
      • GraphQL Gateway - アプリ向けに API を公開する
      • Wantedly Visit で BFF GraphQL サーバーを辞めた理由
      • 実践: GraphQL スキーマ設計(未執筆)
      • API での認可処理 (Authorization)
      • マイクロサービス共通ライブラリ "servicex" の紹介
      • 非同期メッセージング処理入門(未執筆)
      • バッチ処理入門(未執筆)
    • Infrastructure
      • Infrastructure Squad
      • プロダクト開発のための Kubernetes 入門
      • インフラ構成概要
      • リリース・デプロイ戦略を支える技術
      • SaaS を活用する:New Relic, Honeybadger, Datadog
    • Data
      • データ基盤入門
      • レコメンデーション
      • Looker 入門
      • 推薦システムの開発に使っているツール
    • 開発プロセス
      • Git の慣習
      • ポストモーテムの取り組み
      • 負債返済日の取り組み
      • プロダクトの課題発見及び解決
      • ソフトウェアデザインの基礎
      • コードレビュー
      • コーディング規約
      • リリース・デプロイ戦略
      • 上長承認が必要な作業
      • アーキテクチャディシジョンレコード(ADR)
      • 作業ログを残す意味
      • 多言語化対応(i18n)
      • メール開発
    • 開発ツール
      • 社内利用している開発ツールの最新状況
      • kube
      • Code Coverage
      • Kubefork
  • おわりに
    • ロードマップ(未執筆)
    • Handbook の書き方
    • コントリビューター
  • 付録
    • 社内用語集
    • 主要な GitHub レポジトリのリスト(未執筆)
    • 今後の挑戦・未解決イシュー(未執筆)
    • プロダクト開発組織のバリュー(未執筆)
    • 採用についての考え方(未執筆)
GitBook提供
このページ内
  • はじめに
  • どのような作業か?
  • 本番環境のデータを変更する作業
  • ユーザへのメール配信

役に立ちましたか?

  1. 第二部:技術領域への案内
  2. 開発プロセス

上長承認が必要な作業

前へリリース・デプロイ戦略次へアーキテクチャディシジョンレコード(ADR)

最終更新 1 年前

役に立ちましたか?

はじめに

ウォンテッドリーではエンジニアに対して、多くのシステム権限が与えられます。然しながらそのシステム権限の中であれば何でもできるとは限りません。一部の作業においては上長の承認を必要とします。主には行う作業によりシステムに広域または重大な障害が発生するものや多くのユーザ様にご迷惑をおかけする可能性の高いものが該当します。 社内の承認プロセスに応じてシステム権限を操作することは非常に困難なことであり、各エンジニアが承認が必要な作業や、その承認プロセスを把握しておく事により安全なシステム開発・運用が実現されます。

どのような作業か?

以下の 2 点が上長承認を必要とする作業として定義されています。

  • 本番環境のデータを変更する作業

  • ユーザへのメールの配信

本番環境のデータを変更する作業

データベース管理システムの種類や、データ種類(Public / Private な情報か等)は問いません。 本番システムに対して手動でデータ変更をする事、またはデータを変更するプログラムを起動する行為が該当します。

Wantedly のシステムはすべて Immutable Infrastructure となっており、データ変更以外の目的で本番環境へコンソールログインすることはまずありません。 本番環境にコンソールログインし、データを変更する行為は上長承認が必要とシンプルに捉えても良いでしょう。

実際の作業プロセスについては、 を参照して下さい。

ユーザへのメール配信

ここで言うユーザとは Wantedly Visit 等を個人として扱う人、契約企業の管理者・採用担当者等の双方を含むすべての利用者を指します。 またメール送信すべてを指すものではなくメルマガであったり、実装したメール配信バッチやメール配信システム等からのメール送信を指します。

メールの送信については、誤配信やメール文面のガイドライン違反等の問題が発生しやすく、配信したメールを取り戻す事ができません。その特性から上長承認が必要なものとして定義されています。

社内の承認プロセスは常に変化していくものです。少しでも迷ったら周りのエンジニアや上長等に確認を取りましょう。

Production でデータを編集を行うときのガイドライン (internal)