# Infrastructure Squad

## Why

Infra Squad 『プロダクト開発の価値を高速に信頼性高く出力し続ける』をミッションに掲げています。

Dev Tribe では日夜プロダクト開発を行い、ユーザーがシゴトでココロオドルための価値を創出しています。 そのプロダクトの価値を絶え間なくユーザーに提供しつつ、プロダクト開発で生み出した新たな価値を高速に出力するための『システム基盤 / プラットフォーム』を、プロダクト開発と同様に開発し続ける必要があります。

## How

開発チームが Ownership を持って Dev, CI/CD, Ops (Monitoring + On-Call) を行えるように、我々は Platform として Tool/Library/System/Infra を用意します。開発チームが Platform を利用することで、自然と "強いシステム" が "高い生産性" で実現されるようにします。

* "強いシステム" の実現（= Site Reliability）
  * Performant
  * Reliable
  * Maintainable
  * Secure
  * Efficient
* "スケーラブルな開発組織を支える Platform" の実現（= Developer Productivity）
  * Tool/Library/System (= Build)
  * CI/CD (= Test, Deploy)
  * Observability (= Operation)

## What

"強いシステム" の実現のために、我々は "Platform 化" というアプローチを取ります。

具体的には以下のことに取り組みます。ただし、"強いシステム" の実現を考える際も基本的には「開発チームから使われるものを Platform として提供する」ことを念頭においています。

* "強いシステム" の実現
  * マイクロサービスアーキテクチャの強化
    * Availability, Resiliency, Scalability, Performance, Maintainability の向上
    * 以下の重要な関心ごとに対して「開発者が自然に意識できる、自然に適切なアプローチが取れる状態」の構築 => Platform 化
      * 適切な依存関係、組織にあったマイクロサービス境界、適切なインターフェースの宣言的管理、Fallback 機構の充実、通信の信頼性とパフォーマンス向上、非同期通信による結果整合性、バッチジョブの宣言的依存管理、バッチジョブの自動再実行、etc.
  * Cloud Infra の活用と Orchestration Layer の提供
    * AWS, Google Cloud
    * Kubernetes
  * セキュリティ対応・セキュリティレベルの向上
  * 効率的なマシンリソース利用
* "スケーラブルな開発組織を支える Platform" の実現
  * Tool/Library/System の開発・提供
  * 運用自動化 (k8s, terraform の利用)
  * CI/CD
  * Observability 強化 (Monitoring + Alert 強化, Error Rate 可視化)
  * 上記を Platform として提供してセルフサービス化、Ownership を持つ文化の構築
    * 障害検知 + 対応
    * Postmortem
    * Production Readiness Review

また、上記の実現を生産的に行うために、以下にも取り組みます。

* Toilの撲滅
  * 手動オペレーション効率化・自動化
    * Kubernetes Cluster Upgrade
    * K8s Manifest File 更新
    * Incident Issue
    * Postmortem
    * Production Readiness Review
    * 特定の Team のための Infra 構築
  * Support 運用の改善
* 優先度判断が漏れなく行われる体制構築
  * Project と直接紐づかない Task を貯める仕組みと消化する仕組み（= Backlog 消化 Day）

その他、Tool/System に出来てないものは開発チームに Support Issue を立ててもらって対応しています。

* Support

### KPI

* "強いシステム" の実現（= Site Reliability）
  * SLO 99.9 % 以上を維持する
  * 未来の変化を見据えた上で、強いシステムを作るための部品を提供
* "スケーラブルな開発組織を支える Platform" の実現（= Developer Productivity）
  * ヒアリングを通して課題を整理し、エンジニアリングによって解決

## 背景

以下のような Layered Architecture を考えた時、2014 年からは AWS を利用、2016年からは Kubernetes を利用と Layer を積み重ねてきました。Cloud + Kubernetes の Infra Layer を提供し、安定化させるということが行われてきて、年々良くなっています。

```
[Application (= Microservices)]
[Kubernetes]
[Cloud (= AWS, GCP)]
```

一方で、システムが巨大化し、機能が増え、開発チームが大きくなるほど、Application (= Microservices) のレイヤーの重要性が高まっています。この部分は開発チームが担う一方で、一方的に任せていれば良くなるというものではありません。特に、「開発 (Dev)」と「運用 (Ops)」が完全に分離してしまうと、そこに「新機能リリースのための変更（= Reliability 低下）」と「変更阻止（= Reliability 短期的に上昇）」という対立軸が生まれてしまい、開発組織が上手く行かなくなります。

そこで我々は、「Platform 化」というアプローチを取っています。開発チームが Ownership を持って Dev, CI/CD, Ops (Monitoring + On-Call) を行い、我々はそのための Tool/Library/System/Infra を用意します。また、考え方や Best Practice の啓蒙、組織構造の改善など、開発組織の文化・組織的な改善の取り組みも行います。

Platform を提供することで開発 Team の負担を軽減しつつ、開発 Team が Dev から Ops までを責任範囲とする事で強いシステムを作ることへの健全なインセンティブを用意します。具体的には、以下のような姿を開発 Team が実現出来るようにします。

* 強いシステム = 変化出来るシステム
  * <=> 弱いシステム = 変化出来ないシステム
    * 信頼性が低いために、システムを不安定にする「デプロイ」が出来ない => 信頼性が上がらない（むしろ下がる）という悪いループから抜け出せなくなる。
* どう強いシステムをどう実現するか?
  * \=> システムを複数のコンポーネントから作る（= マイクロサービス）
  * マイクロサービス単位で小さく高速に変化可能にする（= 変化出来るシステム）
  * マイクロサービスアーキテクチャ
    * 適切な依存関係
    * 組織にあったマイクロサービス境界
    * 適切なインターフェースの宣言的管理
    * Fallback 機構の充実
    * 通信の信頼性とパフォーマンス向上
    * 非同期通信による結果整合性

短期的には Platform は「開発 Teamの負担を増やす」ように見えますが、長期的にはシステムの安定性を高めつつ各チームが高速に開発を行えるようになるため、全体としての生産性は高まるはずだと考えています。Amazon, Google などの先人に倣う形です。

## Project

* "強いシステム" の実現（= Site Reliability）
  * Improve Monitoring and Alerting and Logging
  * Post-mortem / Incident Review
  * System Architecture
    * Event Driven Architecture
    * RPC framework (e.g. gRPC)
    * Service Mesh
  * Security
  * Efficiency
* "スケーラブルな開発組織を支える Platform" の実現（= Developer Productivity）
  * Dockerized
  * Implement tools for Developer
  * Faster CI/CD
  * Distributed Tracing
  * Mentenance Common library

## SLO/SLI

Wantedly では、サービスの健全性を示す重要な指標として SLI を定義しています。また、目標として SLO も定義しています。

SLI は、「サービスを運営する上で重要な endpoint の成功したリクエストの比率」です。HTTP status code が 5xx 及び 405 (Method Not Allowed) 以外のリクエストを成功と見なします。SLO は「リクエストの 99.9% の成功」です。

## よく使うレポジトリ一覧

インフラメンバー以外の人に知っておいて欲しいレポジトリとその説明を示します。 リンクはすべて internal です。

* [wantedly/k8s（internal）](https://github.com/wantedly/k8s) Kubernetes cluster の設定
* [wantedly/kube-go（internal）](https://github.com/wantedly/kube-go) kube コマンド
* [wantedly/microservices（internal）](https://github.com/wantedly/microservices) microservice を作った際に更新するもの、作り方
* [wantedly/wantedly-terraform（internal）](https://github.com/wantedly/wantedly-terraform) AWS 等のインフラを構築
* [wantedly/secrets（internal）](https://github.com/wantedly/secrets) 秘匿する環境変数の設定
* [wantedly/docs（internal）](https://github.com/wantedly/docs) オフィス系の資料
* [wantedly/internal-proxy（internal）](https://github.com/wantedly/internal-proxy) nginx

## (参考) 利用している SaaS

* [AWS Console](https://wantedly.signin.aws.amazon.com/console)
* [Google Cloud Console](https://console.cloud.google.com)
* [Datadog](https://app.datadoghq.com)
* [PagerDuty](https://wantedly.pagerduty.com)
* [DNSimple](http://dnsimple.com/)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.wantedly.dev/fields/infrastructure/infrastructure-squad.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.