読んだもの、積読、これから買うもの、色々あるが備忘のため記録しておく
基本
↓2024/8/26発売予定
設計
↓2024/8/28発売予定
![エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド](https://m.media-amazon.com/images/I/41IlBoZCfcL._SL500_.jpg "エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド")
「つくって、壊して、直して学ぶ Kubernetes入門」を読んだ🐳
というわけで読了したので気づきや感想やらなんやらをつらつらと📝
目次
- Part 1：つくってみようKubernetes
- Chapter 1 Dockerコンテナをつくってみる
- Chapter 2 Kubernetesクラスタをつくってみる
- Chapter 3 全体像の説明
- Chapter 4 アプリケーションをKubernetesクラスタ上につくる
- Part 2：アプリケーションを壊して学ぶKubernetes
- Chapter 5 トラブルシューティングガイドとkubectlコマンドの使い方
- Chapter 6 Kubernetes リソースをつくって壊そう
- Chapter 7 安全なステートレス・アプリケーションをつくるために
- Chapter 8 総復習：アプリケーションを直そう
- Part 3：壊れても動くKubernetes
- Chapter 9 Kubernetesの仕組み、アーキテクチャーを理解しよう
- Chapter 10 Kubernetesの開発ワークフローを理解しよう
- Chapter 11 オブザーバビリティとモニタリングに触れてみよう
- Chapter 12 この先の歩み方
関連リンク
著者のブログ blux.hatenablog.com
サンプルコードリポジトリ github.com
「Chapter 3 全体像の説明」と「Chapter 4 アプリケーションをKubernetesクラスタ上につくる」から一部を抜粋した記事 codezine.jp
気づきと感想
- 全体を通してハンズオンが豊富でとても楽しく読み進めることができた
- kindでのローカル環境も体験が良く、もうkindでええじゃん！となった
- kubectl debug便利そう
- 周辺エコシステムやPluginの紹介、各種Tipsも参考になる
- Prometheus & GrafanaのデプロイとTraceの確認もハンズオンでカバーしてて良き
- ユーザー管理と認証・権限確認周りについては特に言及なかったけど漫画で書いてくれたらめちゃくちゃわかりやすそう
- Chapter11にはお掃除コマンドがないのでお掃除を忘れないように
誤植
※2024/06/05時点で正誤表に記載のないもので気付いたもののみ記載 www.shoeisha.co.jp
- P.039 （2つ目の実行結果）
Hello, world! Let's learn Kubernetes!→Hello, world! - P.093
-stdin(-i)→--stdin(-i) - P.171
ユーザー名などを変更する可能性があるすべての設定情報に使えます。→ユーザー名など変更する可能性があるすべての設定情報に使えます。 - P.254
今回は簡単のためにDeploymentの→今回は簡単にするためDeploymentの
まとめ
「つくって、壊して、直して学ぶ Kubernetes入門」を読んだ🐳
ハンズオンが豊富で色々な気づきもあり、これからKubernetesを始めるという方の最初に読む本としてとても良いのでは？？となる書籍でした！
会員特典データとして「ArgoCDでGitOps体験してみよう」のPDFがもらえるのでこちらも是非！
HelmでPrometheus Stackをインストールする
自宅のラズパイk8sクラスターにPrometheus Stackを生やしていく
Helm Chart Repositoryを追加
$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
$ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "prometheus-community" chart repository Update Complete. ⎈Happy Helming!⎈
namespaceの作成
$ k create namespace monitoring namespace/monitoring created
helm installの実行
$ helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack NAME: kube-prometheus-stack LAST DEPLOYED: Mon Jun 3 21:26:28 2024 NAMESPACE: monitoring STATUS: deployed REVISION: 1 NOTES: kube-prometheus-stack has been installed. Check its status by running: kubectl --namespace monitoring get pods -l "release=kube-prometheus-stack" Visit https://github.com/prometheus-operator/kube-prometheus for instructions on how to create & configure Alertmanager and Prometheus instances using the Operator.
起動確認
Pod
$ k get po NAME READY STATUS RESTARTS AGE alertmanager-kube-prometheus-stack-alertmanager-0 2/2 Running 0 49m kube-prometheus-stack-grafana-67997d8bd4-wnh9f 3/3 Running 0 49m kube-prometheus-stack-kube-state-metrics-657ddb7877-jcj26 1/1 Running 0 49m kube-prometheus-stack-operator-5975686646-bhk6m 1/1 Running 0 49m kube-prometheus-stack-prometheus-node-exporter-jc6qx 1/1 Running 0 49m kube-prometheus-stack-prometheus-node-exporter-n5hwh 1/1 Running 0 49m kube-prometheus-stack-prometheus-node-exporter-x6kz6 1/1 Running 0 49m prometheus-kube-prometheus-stack-prometheus-0 2/2 Running 0 49m
Grafanaへアクセス
自動生成されたServiceを使ってport-forwardする
$ k port-forward service/kube-prometheus-stack-grafana 8080:80 Forwarding from 127.0.0.1:8080 -> 3000 Forwarding from [::1]:8080 -> 3000 Handling connection for 8080 Handling connection for 8080
http://localhost:8080/login へアクセスしてログイン画面が出ることを確認
デフォルトで以下のログイン情報となっているのでログインしてみる
| username | password |
|---|---|
| admin | prom-operator |
なんて簡単にできるんだ...（感動
HPAを利用するためにインストールしたmetrics-serverが起動しなかったのでトラブルシュートした
自宅のラズパイk8sクラスターでHPAを利用できるようにしようと思い立ち、metrics-serverをインストールしてみたものの、metrics-serverが起動しなかったのでトラブルシュートしてみた
環境
- Kubernetes v1.30.0
- metrics-server v0.7.1
インストール
手順に従いインストールコマンドを実行
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
起動確認
Deployment
READYが0/1のまま...
k get deployment metrics-server -n kube-system NAME READY UP-TO-DATE AVAILABLE AGE metrics-server 0/1 1 0 10h
Pod
metrics-serverだけREADYにならない
k get po -n kube-system NAME READY STATUS RESTARTS AGE coredns-7db6d8ff4d-67gfj 1/1 Running 0 8d coredns-7db6d8ff4d-xlznj 1/1 Running 0 8d etcd-k8s-master01 1/1 Running 0 8d kube-apiserver-k8s-master01 1/1 Running 0 8d kube-controller-manager-k8s-master01 1/1 Running 0 8d kube-proxy-dww28 1/1 Running 0 8d kube-proxy-lb9h2 1/1 Running 0 8d kube-proxy-t9lsn 1/1 Running 0 8d kube-scheduler-k8s-master01 1/1 Running 0 8d metrics-server-7ffbc6d68-pqtdt 0/1 Running 0 10h
Describe Pods
kubelet Readiness probe failed: HTTP probe failed with statuscode: 500
Readiness probeが失敗してしまっているようだ
k describe po metrics-server-7ffbc6d68-pqtdt -n kube-system
Name: metrics-server-7ffbc6d68-pqtdt
Namespace: kube-system
Priority: 2000000000
Priority Class Name: system-cluster-critical
Service Account: metrics-server
Node: k8s-worker01/192.168.1.111
Start Time: Wed, 29 May 2024 23:51:51 +0900
Labels: k8s-app=metrics-server
pod-template-hash=7ffbc6d68
Annotations: <none>
Status: Running
IP: 10.244.1.73
IPs:
IP: 10.244.1.73
Controlled By: ReplicaSet/metrics-server-7ffbc6d68
Containers:
metrics-server:
Container ID: containerd://603b5f91968f0afb410fa3a49786c563bd26f87de59c11ce1d4822e743a7fa29
Image: registry.k8s.io/metrics-server/metrics-server:v0.7.1
Image ID: registry.k8s.io/metrics-server/metrics-server@sha256:db3800085a0957083930c3932b17580eec652cfb6156a05c0f79c7543e80d17a
Port: 10250/TCP
Host Port: 0/TCP
Args:
--cert-dir=/tmp
--secure-port=10250
--kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
--kubelet-use-node-status-port
--metric-resolution=15s
State: Running
Started: Wed, 29 May 2024 23:52:00 +0900
Ready: False
Restart Count: 0
Requests:
cpu: 100m
memory: 200Mi
Liveness: http-get https://:https/livez delay=0s timeout=1s period=10s #success=1 #failure=3
Readiness: http-get https://:https/readyz delay=20s timeout=1s period=10s #success=1 #failure=3
Environment: <none>
Mounts:
/tmp from tmp-dir (rw)
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-6szcf (ro)
Conditions:
Type Status
PodReadyToStartContainers True
Initialized True
Ready False
ContainersReady False
PodScheduled True
Volumes:
tmp-dir:
Type: EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit: <unset>
kube-api-access-6szcf:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: Burstable
Node-Selectors: kubernetes.io/os=linux
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Unhealthy 4m41s (x4114 over 10h) kubelet Readiness probe failed: HTTP probe failed with statuscode: 500
Logs
k logs metrics-server-7ffbc6d68-6srfk -n kube-system I0530 03:08:07.651554 1 serving.go:374] Generated self-signed cert (/tmp/apiserver.crt, /tmp/apiserver.key) I0530 03:08:08.554701 1 handler.go:275] Adding GroupVersion metrics.k8s.io v1beta1 to ResourceManager I0530 03:08:08.686371 1 requestheader_controller.go:169] Starting RequestHeaderAuthRequestController I0530 03:08:08.686459 1 shared_informer.go:311] Waiting for caches to sync for RequestHeaderAuthRequestController I0530 03:08:08.686466 1 configmap_cafile_content.go:202] "Starting controller" name="client-ca::kube-system::extension-apiserver-authentication::client-ca-file" I0530 03:08:08.686518 1 shared_informer.go:311] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::client-ca-file I0530 03:08:08.686517 1 configmap_cafile_content.go:202] "Starting controller" name="client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file" I0530 03:08:08.687032 1 shared_informer.go:311] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file I0530 03:08:08.689211 1 dynamic_serving_content.go:132] "Starting controller" name="serving-cert::/tmp/apiserver.crt::/tmp/apiserver.key" E0530 03:08:08.689974 1 scraper.go:149] "Failed to scrape node" err="Get \"https://192.168.1.101:10250/metrics/resource\": tls: failed to verify certificate: x509: cannot validate certificate for 192.168.1.101 because it doesn't contain any IP SANs" node="k8s-master01" I0530 03:08:08.690832 1 secure_serving.go:213] Serving securely on [::]:10250 I0530 03:08:08.691791 1 tlsconfig.go:240] "Starting DynamicServingCertificateController" E0530 03:08:08.692009 1 scraper.go:149] "Failed to scrape node" err="Get \"https://192.168.1.112:10250/metrics/resource\": tls: failed to verify certificate: x509: cannot validate certificate for 192.168.1.112 because it doesn't contain any IP SANs" node="k8s-worker02" E0530 03:08:08.701807 1 scraper.go:149] "Failed to scrape node" err="Get \"https://192.168.1.111:10250/metrics/resource\": tls: failed to verify certificate: x509: cannot validate certificate for 192.168.1.111 because it doesn't contain any IP SANs" node="k8s-worker01" I0530 03:08:08.786953 1 shared_informer.go:318] Caches are synced for RequestHeaderAuthRequestController I0530 03:08:08.787115 1 shared_informer.go:318] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::client-ca-file I0530 03:08:08.788043 1 shared_informer.go:318] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file E0530 03:08:23.685957 1 scraper.go:149] "Failed to scrape node" err="Get \"https://192.168.1.112:10250/metrics/resource\": tls: failed to verify certificate: x509: cannot validate certificate for 192.168.1.112 because it doesn't contain any IP SANs" node="k8s-worker02" E0530 03:08:23.692988 1 scraper.go:149] "Failed to scrape node" err="Get \"https://192.168.1.111:10250/metrics/resource\": tls: failed to verify certificate: x509: cannot validate certificate for 192.168.1.111 because it doesn't contain any IP SANs" node="k8s-worker01" E0530 03:08:23.695203 1 scraper.go:149] "Failed to scrape node" err="Get \"https://192.168.1.101:10250/metrics/resource\": tls: failed to verify certificate: x509: cannot validate certificate for 192.168.1.101 because it doesn't contain any IP SANs" node="k8s-master01" I0530 03:08:36.493054 1 server.go:191] "Failed probe" probe="metric-storage-ready" err="no metrics to serve"
ログからmetrics Serverが起動しない原因は、Kubeletの証明書がIP SAN（Subject Alternative Name）を含んでいないため、TLS検証が失敗していることっぽいことがわかったのでTLS検証を無効化していく
TLS検証の無効化
というわけで現状自宅のラズパイk8sクラスターはkubelet証明書がクラスター認証局に署名されていないのでargsに--kubelet-insecure-tlsを渡して証明書の検証を無効化していく
k edit deploy metrics-server -n kube-system
template: metadata: creationTimestamp: null labels: k8s-app: metrics-server spec: containers: - args: - --cert-dir=/tmp - --secure-port=10250 - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname - --kubelet-use-node-status-port - --metric-resolution=15s - --kubelet-insecure-tls # ←こいつを追加
再度動作確認
Pods
k get po -n kube-system NAME READY STATUS RESTARTS AGE coredns-7db6d8ff4d-67gfj 1/1 Running 0 12d coredns-7db6d8ff4d-xlznj 1/1 Running 0 12d etcd-k8s-master01 1/1 Running 0 12d kube-apiserver-k8s-master01 1/1 Running 0 12d kube-controller-manager-k8s-master01 1/1 Running 0 12d kube-proxy-dww28 1/1 Running 0 12d kube-proxy-lb9h2 1/1 Running 0 12d kube-proxy-t9lsn 1/1 Running 0 12d kube-scheduler-k8s-master01 1/1 Running 0 12d metrics-server-d994c478f-8f7hh 1/1 Running 0 23m
Deployments
k get deploy -n kube-system NAME READY UP-TO-DATE AVAILABLE AGE coredns 2/2 2 2 12d metrics-server 1/1 1 1 3d10h
というわけで無事起動させることができた！
DockerのCI改善に寄与しそうなリンク・Tips・ツールたち
リンク
NIST SP 800-190 Application Container Security Guide
コンテナセキュリティの国際的なガイダンス
コンテナに関するセキュリティ上の考慮ポイントが網羅されている csrc.nist.gov
CIS Docker Benchmark
ツール
Trivy
Aqua Security Software社が提供する脆弱性ツール
コンテナOSパッケージやプログラムの各言語に関連した依存関係などをスキャンしてくれる github.com
Hadolint
DockerfileのLintツール
DockerのベストプラクティスやShellCheckによる静的解析ツールのチェック項目が組み込まれている
Dockle
ビルドされたイメージに対して、DockerのベストプラクティスやCIS Docker Benchmarksで求められる項目をチェックしてくれる
Kritis Sgner
Kritis Signer はオープンソースのコマンドライン ツールで、構成したポリシーに基づいて Binary Authorization 証明書を作成できるツール
kaniko
Googleが中心となって開発したOSS
特定のコンテナランタイムに依存しないコンテナイメージビルドが可能
kanikoを利用してビルドするとDockerfileの各コマンドごとにそれぞれスナップショットを作成＆レイヤーとして保存してイメージを作成してレジストリにプッシュする
レイヤーごとに作成されたイメージ情報は次回ビルド時にキャッシュとして利用できるのでレイヤの変更がなければビルド時間の短縮ができる
Tips
公式配布のベースイメージかどうかのチェック
現状、公式配布のベースイメージかどうかのチェックができるツールはないので、以下をCIに組み込むことで対応できる
docker search --filter is-official=true <IMAGE_NAME>
Hadolintでも関連IssueがあるのでHadolintで対応される日が来るかも？
Kubernetes運用のTips
Kubernetes運用関連で自身が遭遇した事象への対処の備忘録としてTips集的にエントリを育てていく
Kubernetesで消えないPodを強制的に削除する
まれにkubectl delete podsしてもPodが消えてくれないことがあり、その時は--grace-period=0, --forceオプションを付けることで強制的に削除することができる。
kubectl delete pods {$pod_name} --grace-period=0 --force
この方法はkubeletからの確認を待たずに強制的に削除するので、Podのプロセスが完全になくならなかったりほかのリソースとの競合などが起こりえる。 この方法を常に行うような状況の場合は原因を追究する必要がある。
| Option | Description |
|---|---|
--grace-period=0 |
正常に終了するためにリソースに与えられる秒単位の時間。負の場合は無視されます。即時シャットダウンするには 1 に設定します。 --force が true (強制削除) の場合にのみ 0 に設定できます。 |
--force |
true の場合、API からリソースを直ちに削除し、正常な削除をバイパスします。一部のリソースをすぐに削除すると、不整合やデータ損失が発生する可能性があるため、確認が必要であることに注意してください。 |
TLS証明書のエラー
kubectlコマンド実行時に以下の様なエラーで接続できない場合、証明書の不一致が原因である可能性が高い
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
kubeconfigを確認して実行元で持っている情報と差分がないかを確認する
「世界一流エンジニアの思考法」を読んだ
今更ながら読了📕
— 𝕋𝕠𝕔𝕪𝕦𝕜𝕚 𝕏 (@Tocyuki) 2024年4月6日
学びや共感も多く、サクサク読めてしまった。批判文化についてはほんとそうだよなぁとしみじみ。
『世界一流エンジニアの思考法 (文春e-book)』(牛尾 剛 著) を読み終えたところです https://t.co/fClvMjiLL1 pic.twitter.com/PQS45gr9Hy
というわけで世界一流エンジニアの思考法を読了したので今更ながら備忘録的な書評を書いてみる📕
この書籍は米マクロソフトシニアエンジニアでAzure Functionsの開発者である牛尾剛さんが執筆した書籍
牛尾剛さんのnoteやブログがきっかけに発足した執筆プロジェクトとのことでnoteの記事もちょこちょこ見てみたがとてもおもしろいので興味があればこちらも是非！
目次
- 第1章 世界一流エンジニアは何が違うのだろう？ - 生産性の高さの秘密
- 「生産性の高さ」の違い
- トップエンジニアの衝撃的な解決方法
- 試行錯誤は「悪」である
- 頭が良くても「理解」には時間がかかる
- 「理解に時間をかける」を実践する
- 複雑な技術をコントロールできている感覚を得る
- 「感覚」で批判せずファクトを積み重ねる
- 小さなドキュメントをコードの前に書く
- 頭の中に「メンタルモデル」をつくる
- まずエキスパートに頼る
- 「偉大な習慣を身につけたプログラマ」になる
- 第2章 アメリカで見つけたマインドセット - 日本にいるときにはきづかなかったこと
- 「Be Lazy」というマインドセット
- いかにやることを減らすか？
- 一つだけピックアップする
- 時間を固定して、できることを最大化する
- 「準備」「持ち帰り」をやめてその場で解決する
- 物理的にやることを減らす
- リスクや間違いを快く受け入れる
- 失敗を受け入れる具体的な実践法
- 「フィードバック」を歓迎するムードをつくる
- 「検討」をやめて「検証」する
- 「早く失敗」できるように考える
- 不確実性を受け入れよう
- バリューストリームマッピングで「見える化」する
- 「思考回路」を形作る実践
- 「楽に達成できる」計画で仕事をする
- 「無理・断る」練習をする
- 他の文化の視点を学んでみる
- 「結果を出す」から「バリューを出す」へ
- 第3章 脳に余裕を生む情報整理・記憶術 - ガチで才能のある同僚たちの極意
- コードリーディングのコツは極力コードを読まないこと
- いかに脳みその負荷を減らすか
- 仕事の難易度別で考える
- 「アウトカム」至上主義が上達を阻害する
- マルチタスクは生産性が最低なのでやらない
- 1日4時間は自分だけの時間を確保する
- なぜ同僚たちは「記憶力」がいいのだろう
- 「書く」すすめ
- 頭の中のみで整理する
- 理解・記憶・反復という黄金則
- 第4章 コミュニケーションの極意- 伝え方・聞き方・ディスカッション
- 「情報量を減らす」大切さ
- 準備は効く ---伝え方のコツ
- 相手が求めている情報への感度を研ぎ澄ます
- コードを「読み物」として扱う
- ミスコミュニケーションのサイン
- クイックコールのすすめ
- クイックコールされる側もよいことがある
- 気軽に聞ける空気の大切さ
- ディスカッションで鍛えられること
- 意見が対立しても「否定しない」
- 「会話力」を育てよう
- 第5章 生産性を高めるチームビルディング - 「サーバントリーダーシップ」「自己組織型チーム」へ
- 「サーバントリーダーシップ」とは何か
- 自己組織チーム/フィーチャーチーム
- 開発者それぞれが責任を持って設計し実装する
- 「仕事を楽しんでいるか？」を確認する文化
- ボスの役割はサポートすること
- 納期がなく、マネージャも急かさない
- 自己組織チームをいかに導入するか
- チームの上下関係をなくす
- 失敗に寛容な職場がチャレンジ精神を生む
- 「Be Lazy」を推奨し、休暇を尊重する
- チームにパワーを持たせることの価値
- 第6章 仕事と人生の質を高める生活習慣術 - 「タイムボックス」制から身体づくりまで
- 同僚たちのワークライフバランス
- 生産性を上げたければ定時上がりが効率が良い
- 「タイムボックス」制で、学習の時間を確保する
- 「脳の酷使をやめる」三つの工夫
- 違うことをするのがリフレッシュに
- 掃除で「人生をコントロールする感覚」を取り戻す
- 整理の技術
- 物理的なエネルギー不足をどう解消するか
- テストステロンを意識的に増やす
- 第7章 AI時代をどう生き残るか？ - 変化に即応する力と脱「批判文化」のすすめ
- AIと過去のテクノロジーの違い
- どんな職業ならAIに食われないだろう？
- ChatGPTがやってきたときアメリカで起こっていたこと
- AI時代には「専門性」こそが強みとなる
- 日米のエンジニアを取り巻く文化の違い
- 「批判」の文化がすべてをぶち壊しにする
- コントリビュートと感謝のループ
- 日本再生への道すじ
- 自分の人生は自分でコントロールする
読書メモ
自分が読んでいて学びになったことをつらつらと
- 「基礎」練習は「誰でもできる」ことだが、習得には「時間がかかる」ものなので遠回りせず習得すべし
- 手を動かす前にDesignDocを書いて整理してから作業に取り掛かり、それをナレッジとしてシェアする
- 頭の中にメンタルモデルを意識的に構築する癖をつける
- 会議では「準備」、「持ち帰り」をやめてその場で解決させる
- 不確実性を受け入れられるような文化の醸成に努める
- KPIは定時で無理なく楽に達成できる程度のものであるべき
- コードリーディングの際は実装はちゃんと動いていると信じて極力見ずにインターフェイスと構造を理解するようにする
- 仕事の難易度別で考え、Level1を増やしていく
- Level1: 何もググらず即座に実装できるもの
- Level2: 問題をどう解決するかはすぐに思いつくが、具体的な方法は忘れているのでググる必要があるもの
- Level3: 解法を知らないが、スパイクソリューションをしたらできそうなもの
- Level4: 自分では解決が難しい、もしくはものすごく時間がかかるもの
- エンジニア、プログラマは積み重ねが大事なのでアウトカム勝負だけではない
- マルチタスクは絶対やめる
- 「作業内容を人にそらで説明できるかどうか」を記憶できたかのチェックポイントにする
- 「エビングハウスの忘却曲線」を意識した振り返りで記憶を定着させる
- チーム全体が強くなるためには、気軽に互いのち県を交換できるコミュニケーション文化が大切
- サーバントリーダーシップ型のマネジメント手法においてリーダーはビジョンとKPIは示すが、実際にどのように達成するかはチームが考え意思決定する
- メンバーが楽しんでいるかを重視する
まとめ
「世界一流エンジニアの思考法」を読んだ！
全体的にとても学びと共感が多かったが、「第3章 脳に余裕を生む情報整理・記憶術」では昨年読了した書籍「プログラマ脳」にも通ずる話も多く合わせて読むとより理解が深まりそうだと思った。
この書籍の売れゆきがとても好調で牛尾さんのメディアへの露出が激増していたのだが、その中でもけんすうさんとの対談が個人的に面白かった。
また248ページという量でサクッと読めるのでとてもおすすめです！
エンジニアリングにおけるさまざまな成熟度モデル
オペレーション成熟度
Service Reliability Hierarchy
SRE成熟度評価シート
Observerbillity成熟度
おわりに
ここに全部書いてあった... zenn.dev
マイクロサービスの課題感を感じるためのリンク集
他社SREチームのミッションについて調べてみる
現職のSREチームのMVVを検討し始めてるので他社のMVVについて調べてみる
NewsPicks
SmartShopping
- ミッション
- 日常を革新するプロダクトが走り続けるために、整備された道とガードレールを作り改善していく
- ビジョン
- 自律して信頼性の高いプロダクトを作り続けられるスマートな開発組織の実現
- バリュー
- Bold and Flexible
- Automation
- One for All
- Data Driven
- Proactive
dely
delyが持つ熱量と幸せをできるだけ多くの人に届けられるように、プロダクトの価値最大化をシステム運用において実現する。 その過程において最善の選択が何であるかを考え、システムの設計と運用を改善し続ける。
『スタディサプリENGLISH』 SREグループ
- ミッション
- 自分たちの持つ専門性を活かし、開発者が開発に集中して最大限の力を発揮できる状態を目指す
- ビジョン
- 品質も効率もあきらめない！イケてる環境を作る
『スタディサプリ小中高』 SREグループ
- Mission
- 自己完結チームがプロダクトを素早く安全に届け続けるためのプラットフォームと文化を作る
- Vision
- 最高の学習プロダクトを作り続けられる開発組織の実現
- Values
- Fail smart
- Learning
- Borderless
- Metrics-driven
STORES
ユーザーにたくさんの価値を素早く提供できるようにしながら、事業の成長を阻害する要因を取り除く
レバレジーズ
SRE化を通して、Developer Experienceの改善、事業の拡大への対応、お客様に信頼されるサービスの提供を実現する
Sansan BillOne
eureka
- Mission
- SREプラクティスを開発組織にインストールしていく
- Vision
- 自律的にリライアビリティとアジリティを両立するプロダクト開発組織の実現
- Values
- Metrics First
- 主観ではなく、計測した定量的な指標に基づいて意思決定する
- Draw a Blueprint
- 物事のAsIs — ToBeを自ら描いて自ら実現していく
- No Blame
- 非難をしない、問題を回避したり最小化したり隠蔽するのではなく問題を明らかにしていく
- Learning Animal
- 現状に甘んじず、ToBeを描くために貪欲にインプットし続けていく
- Change Agent
- 組織に忖度せず、必要なことについて議論を恐れず、やるべきことは自らが主導となって働きかける
- Metrics First
mercari Microservice SREチーム
- マイクロサービスチーム特有の事情に合わせた信頼性向上のサポートを行うEmbedded SREs
- 組織全体にSREプラクティスを広めていく
- Platformチームが開発するマイクロサービス基盤の新しい機能の導入を支援する
M3
- エムスリーが提供するサービスのシステム基盤について、現在から将来に渡って高い信頼性やセキュリティを保った管理・運用を行うことで、顧客が安心して快適にサービスを利用できるようにする。
- ビジネス要求や環境の変化に素早く柔軟に対応できるようなシステム基盤を実現し、スケール可能なチームづくりとその維持を行う。
カヤック
明確なミッションが書かれているわけではないが参考になるので貼っておく
色々な会社のCTO室設立の背景やミッションについて調べてみる
今所属している会社にもCTO室があるが、他の会社がどのような背景・目的・役割でCTO室を設けているのか気になったので調べてみる。 インターネットで雑に検索して出て来たものをいくつかピックアップし、設立の背景・目的、ミッションなどで共通項があるかなどを見てみる。
ZOZO
設立の背景・目的
VPoEが2018年度に担っていた動きをチームとして対応できるようにするためにCTO室が設立されました。
ミッション
MIXI
設立の背景・目的
詳細は不明
CTO室は2019年5月にできました。前身はモンストの開発・運用をしていた事業本部内にて、複数のサービスに関わるエンジニアを集めてできた開発本部の下部組織でした。現在は事業部を横断した開発者支援や、事業部内のサービス、プロジェクトに入って個別支援を行っています。
ミッション
CTO室は主に以下の4つのミッションがあります。 1つ目の「サービス技術の設計、開発、保守の研究および開発」というミッションでは、最新の技術動向を追跡し、それを調査・検証しています。これにより、サービスの価値向上をリードする役割を果たしています。 次に、「ものづくり人材の育成」というミッションは、社内エンジニアの育成に重点を置いていますが、同時に渋谷区などの高等専修学校への教育サポート活動も行っています。 「QAの改善活動」は、サービス品質の向上だけでなく、各事業部に継続的な改善プロセスや手順を提供し、その実践を支援することをミッションとしています。 最後に、「データのKPI設計や分析の支援」では、データ活用に関する考え方やアプローチを企業全体に展開しています。KPI設計やデータ分析を通じて、サービスのパフォーマンスを評価し、事業部や経営層の意思決定をサポートしています。
KAONAVI
設立の背景・目的
事業会社ですから、個々の機能のリリースや突発的なパフォーマンスの改善などのほうが、どうしても優先されます。その都度いろいろなチームにヘルプとして呼ばれる、というような状況でした。正直、それだと横軸の改善作業は全然進まない状態だったんですね。ですから、いわゆる全社的な改善作業をするチームを切り分けようというのが、CTOの松下さんが、これまでのプロダクト本部とは別にCTO室という組織を立ち上げた意図だと思います。
ミッション
CTO室の役割は、課題を自分たちで見つけてきて、それを改善することです。課題はたくさんあるので、できることから手をつけていくしかありません。その際に意識しているのは、「カオナビ」の開発効率が上がって、より顧客に対する価値提供をスムーズに行えるようになることです。逆に言えば、そこさえブレなければ手法は何でもいい。
YOUTRUST
設立の背景・目的
不明
ミッション
CTO室では、インフラやセキュリティなどのいわゆる共通基盤や事業部のミッション外ではあるが会社として必要な技術領域の取り組みを行なっています。
DMM
設立の背景・目的
CTO就任とともに発足？
ミッション
簡単に言えば、CTOの想いを実現させる部署です。CTOが就任した後、弊社ではDMM Tech Visionを発表しています。私たちがやるべきことは、その実現です。そのために、現在は3つのチームに分かれて活動をしています。 まずは、制度設計やブランディングを担当するエバンジェリストチーム。技術のスペシャリストで結成されたチームで、人事と接点を持ちながらエンジニアのスキルアップを支援したり、技術広報をしたりと、対外的な活動も行います。 そのほかに、事業支援チームと技術支援チームがあります。事業支援チームは、読んで字のごとく事業部に対して技術的な側面から事業支援を行う組織です。コードを書くなど実務的なサポートもしますが、事業成長に貢献することをミッションに置いており、組織開発からシステム開発までなんでもこなします。 技術支援チームの役割は、社内エンジニア向けの共有ツールを開発したり、自社運用していたシステムのクラウド化を推進したり、全社単位での技術支援を行うことです。基本的にはこの3チームが力を合わせ、DMM.comのテックカンパニー化を推進しています。
レバテック
設立の背景・目的
レバテックにおけるシステム・データの課題を解決をリードしていくため
ミッション
ベルフェイス
設立の背景・目的
ちなみに、CTO室設立の背景として、ベルフェイスの開発環境がお世辞にも整ったものではなかったということが挙げられます。上記の3点に取り組み、CTOや開発メンバーがやりたいと思ったことを実現するための環境づくりを行うことで、プロダクト作りを推進しています。
ミッション
端的に言うと以下の3つに取り組んでいる組織です。 1.システムの安定稼働 2.開発プロセスの健全化 3.無理無駄の撲滅 総じてリーンでアジャイルな開発体制を確立し、QCDFを向上させることに注力しています。
Hey
設立の背景・目的
僕がCTOになって仕事を抱えすぎて辛そうにしているのを見て、社長の佐藤が、heyの中にいるCTO経験者を集めてチームにしてみてはどうかと提案してくれました。どの会社にも、会社を横断した課題を解決する箱があるものです。heyの場合はプロダクトごとに組織がわかれていますが、目指していることはひとつ。横断だからできることや、個別のチームだけでは解決できないことをCTO室の裁量で解決するためにこのチームができました。
ミッション
事業的に目指すところがある程度わかっていて、未来の目標も共有できているメンバーが集まって、さまざまなことを解決しています。例えば、組織マネジメントの課題として、今の組織の形をどうしたらもっと良くできるか、などです。他にも、採用基準、評価、査定、異動など。組織を運営している上で起こる、事務的でもあり、難しい判断が必要なことを解決しています。 また、技術的に横断でやったほうがいい仕事もここで話し合っています。モバイルアプリや、インフラなどのテクノロジーをどう考えるか、などです。
マネーフォワード
設立の背景・目的
DB分割のためのチームを作ったことがきっかけでCTO室という組織を作りました。
ミッション
全社的な、あるいは複数のサービスにまたがるような技術的負債の返済を主なミッションとした組織です。各サービスチームの意思決定はどうしても個別最適な意思決定になりがちなので、時には全体最適で意思決定して取り組む必要がある課題も出てきます。 私はCTO室を作って以来、全体最適の取り組みにアサインするべきリソースをCTO室で確保するようにしていて、タイミングによって増減はありますが、おおむね10-15%ぐらいのエンジニアにCTO室で働いてもらってます。 各サービスの開発チームにアサインされているエンジニアの人事権は私にはありませんが、CTO室のリソースは全社的な課題にアサインしたり、その時に最もフォローが必要なサービス開発チームを支援したり等の調整弁になっていて、リソース調整のスピードと柔軟性を高めることに役立っています。
各社のCTO室設立の背景・目的まとめ
- VPoE, CTOの負担軽減
- 全社横断な課題解決組織として発足
各社のCTO室ミッションまとめ
- ZOZO
- 全社における技術的な戦略策定および、エンジニア組織強化のための施策の推進
- MIXI
- サービス技術の設計、開発、保守の研究および開発
- ものづくり人材の育成
- QAの改善活動
- データのKPI設計や分析の支援
- KAONAVI
- 開発効率が上がって、より顧客に対する価値提供をスムーズに行えるようになること
- YOUTRUST
- インフラやセキュリティなどのいわゆる共通基盤や事業部のミッション外ではあるが会社として必要な技術領域の取り組み
- DMM
- CTOの想いを実現させる、DMM.comのテックカンパニー化を推進
- レバテック
- 事業拡大に伴い、既存の複数サービスとこれから立ち上がるサービス含めて総合的にアーキテクチャや設計を考え、開発や事業をリードしていくための組織
- ベルフェイス
- システムの安定稼働
- 開発プロセスの健全化
- 無理無駄の撲滅
- 総じてリーンでアジャイルな開発体制を確立し、QCDFを向上させることに注力
- Hey
- 事業的に目指すところがある程度わかっていて、未来の目標も共有できているメンバーが集まって、さまざまなことを解決
- 採用基準、評価、査定、異動など組織を運営している上で起こる、事務的でもあり、難しい判断が必要なことを解決
- 技術的に横断でやったほうがいい仕事もここで話し合っています。モバイルアプリや、インフラなどのテクノロジーをどう考えるか
- マネーフォワード
- 全社的な、あるいは複数のサービスにまたがるような技術的負債の返済を主なミッションとした組織
まとめ
各社のCTO室について設立の背景やミッションについて調べてみた。 当たり前に各社様々な目的や背景、ミッションを持っているが大枠では「全社横断で解決すべき課題を解決するための組織」という部分が共通しているのかなと思った。
これらの調べてた内容を元に自組織の運営に活かしていきたい。
2023年の振り返りと2024年の抱負
油断していたら2022年の振り返りをすっ飛ばし、2023年の振り返り記事を上げる前に年を越してしまった。 ここ数年は個人的にかなり濃密な日々となっているのでしっかり振り返って、来年の抱負も掲げてしっかりやっていきたい。
過去の振り返りとか見ていると、かなり忘れている出来事も多く、そして掲げた目標もほぼ達成できてなくてなんて適当なやつなんだと笑えてくるが日々楽しく幸せな人生を過ごせているし、奥さんとも仲良しだし、着実に成長も実感出来ているし、2023年も大いに飛躍出来た一年となった(?)のでﾖｼ!!!
しかし自分は本当にある意味場当たり的に一生懸命生きている運の良いだけの人間なのだなぁと痛感し、持たざる者であることを自覚し、これからもできる範囲で頑張らないといけないなぁ、という気持ち（ｶﾞﾝﾊﾞﾚ
2023年振り返り
まず仕事、登壇＆コミュニティ活動という切り口で出来事やイベントを羅列し、それぞれ印象的な出来事を中心に深掘りながら最後に総括という形で全体を振り返っていこうと思います！
仕事
- CES参加に伴うアメリカ出張（1月）
- チーム合宿と称してトスラブ箱根和奏林でワーケーション（5月）
- イオンスマートテクノロジー社へ転職（8月）
- グループ会社視察に伴う中国出張（9月）
- テックブログ開設＆DevRel立ち上げ（9月）
- MS Ignite Japan recap参加に伴う大阪出張（12月）
- アドベントカレンダー実施（12月）
年始早々（1/3〜1/9）CES視察と称した自身初となるアメリカを出張という形で訪れることになった。 これも初となるホノルルで10時間以上あるトランジットを正月からヨットで回遊しながら休憩ポイントでは船上でハンバーガーを作って食べたり海で泳いだりして満喫し、そこからLAへ行きグランドキャニオンのツアーへ参加したり、戻ってからは初カジノで$1,100勝ちからの$500負けでフィニッシュしたり、CESへも参加したり、シルクドソレイユの「O」を観覧したり、フェニックスではWaymo、サンフランシスコではGMクルーズのレベル4自動運転による無人タクシーを体験したりと本当に色々と貴重な体験をすることが出来た。
また2023年はIT健保のレストラン巡りと保養施設でのワーケーションがQOLを高めてくれた。特にIT健保寿司として名高い「一新」や和食レストラン「木都里亭」とチーム合宿と称して行ったトスラブ箱根和奏林はめちゃくちゃ良かった。IT健保加入してるエンジニア諸氏におかれては是非訪れてほしい。
IT健保の素晴らしいレストラン、保養施設について、また活用戦略については前職のマイメンが記事を書いてくれているのでこちらも是非参考にしてほしい。
2023年最大のイベントは何と言ってもやはり転職だった。
前述の通り、8月にイオンスマートテクノロジー社へCTOのリファラルで転職した。
SREとしてはチームの状態を整えるために詳しくは書けないが色々と精神をすり減らしながら奔走した5ヶ月だった。 中々の苦行だったが種まきを何とか年内に終わらせることが出来たので、2024年はしっかりと成果を上げていきたい。
詳細が気になる方は飲みに誘っていただければベラベラ喋ると思いますのでお誘いお待ちしております🍺
また、中に入ってみて内部への働きかけより外部からのプレゼンスを高めることが色々と近道だと判断し、テックブログやDevRelチームの立ち上げ、アドベントカレンダーの実施などにチャレンジをした結果、これらの活動を通じてエンジニア組織としてのプレゼンスをかなり高めることができた。 特にDevRelチームは増幅拡大の装置としては申し分ない機能を持たせることができたので、今年は採用活動と組織改革を本格的に推進していき強固な地盤固めを行う一年としていきたい。
関連記事は以下
俺の役割 is 何？という風に感じられる方もいると思うが、前向きな言い方をすると必要なことであれば何でもやれるフェーズであるということです。
登壇・コミュニティ活動
- Cloudflare Meetup Nagano Vol.1開催（4月）
- 俺たちのSREとNew Relic -書籍編- 出版＆技術書典14出展（5月）
- NRUG (New Relic User Group) SRE支部 Vol.3開催（6月）
- Cloud in the Camp 勝浦（7月）
- JAWS-UG コンテナ支部 #24 ecspresso MeetUp登壇（8月）
- FutureStack Tokyo NRUG 2周年特別版開催（9月）
- Cloudflare Meetup Nagano Vol.2開催（10月）
- CloudNative Days Tokyo 2023 Keynote登壇（12月）
2023年はコミュニティ活動を通じて色々な人と接点を持ったり仲を深める事ができた。 今までコミュニティに関わることで人生が変わった、というような人の話を聞く事がよくあったが、昨年はまさに自分の人生も様々なコミュニティを通じて拡張されていく感覚があった。 今では自分の言葉として「コミュニティに関わることで人生が変わった」と言えるようになったと思う。
ハイライトとしてはCloudflare Meetup Naganoを主催(?)し、長野の技術コミュニティの方々と繋がることが出来たり、NRUG SRE支部メンバーで共著で書籍を出版したり、JAWS-UG コンテナ支部 #24 ecspresso MeetUpでは敬愛するfujiwaraさんやsongmuさんと一緒にお酒を飲んだり、Cloud in the Camp 勝浦で色々な人と交流できたあたりだと思う。
また例年よりも多くの様々なイベント（登壇や主催以外の）へオンライン、オフライン問わず参加したような気がする。
引き続き自分の人生をより豊かにし、学びを得るため、また還元するためにも積極的にコミュニティ活動やイベントへ参加して行こうと思う。
総括
2022年もそうだったが、2023年も本当にイベントや変化の多い一年になった。
なんと言っても転職したことによる変化が一番大きかったが、仕事的にはこの一年で初めてアメリカと中国へ海外出張に行ったり、本を出版したり、ワーケーションと称して伝説のトスラブ箱根和奏林に行ったり（マジ最高だった）、プライベートでは千葉と四国へ家族旅行したり、消防団やサッカーのコーチを始めたり、マイカーを購入したりと人生においても記憶に残るであろう良い経験となるイベントが目白押しでとても良い一年となった。
転職して大変な時期もあったりしたが、あの手この手でなんとか光が見える状況にはなって来たので今年は方針策定して大きな成果を創出していきたい。
ここ数年は仕事のみならず自分の戦略・戦術がハマることが多いのだがディテールが甘かったり大雑把な部分は散見されるのでそういった部分は改善していき、より良い人生を歩めていけるように精進していきたい。
2024年の抱負
個人的な今年の抱負としては以下についてそれぞれ習慣化のための施策を遂行できるように頑張っていきたい。 2024年は継続力をキーワードに習慣化を進めていきたい（自信ないけど）
- 読書
- フォーカスすべき技術領域の学習
- 英語学習
- 健康
全体の共通施策として「毎週日曜に振り返りと計画を行う」ことを継続していきたい。
読書
主に技術書が対象になると思うが、以下のような施策をしっかりと遂行していきたい。
- 計画的な積読消化による読書の習慣化
- アウトプット駆動読書
- 輪読会の開催
後述するフォーカスすべき技術領域の学習にも関係するが、年間でどれぐらい何を読むかをある程度計画し、読み終わったら書評を書くなどアウトプットとセットで読むようにする。 また、会社のメンバーを巻き込んで輪読会を実施しチーミングも兼ねて相互で学習する仕組みを作り上げる。
読書管理にはブクログを活用するようにする。
フォーカスすべき技術領域の学習
自分は今までなんでもできるようになりたいという気持ちが強く、学習対象もかなり散漫だったが今後は明確に以下の領域に絞り、Infra/DevOps/SRE/PlatformEngineering領域を強みとしたエンジニアとしてしっかり市場価値も上げていき、会社・事業にもコミットしていきたい。
- Golang
- Kubernetes
- DevOps
- SRE
- PlatformEngineering
どのように学習していくかは基本的にはインプットとアウトプットになるわけだが、その主軸は以下だ。
- 技術書、ハンズオン、実践を通したインプット
- ブログ、登壇などによるアウトプット
すでに今年もデブサミへの登壇も決まっていたり、TiUGやAEON Tech Talkなどのイベント開催も予定しているのでそれらのイベントやSRE Next、PlatformEngineeringMeetup、CNDTなど大きなカンファレンスでの登壇にもどんどん挑戦していきたい。
そして今年はISUCONにも挑戦したい！！
英語学習
月並みだが以下のアプリでの学習を毎日やる！
- Duolingo
- ELSA Speak
- iKnow
健康
とりあえず意識しながら無理せずという感じで頑張りたい。
- コーチ業では意識して動く
- 息子とのサッカー練習では自分の運動も兼ねてやる
- 毎日ストレッチする
- 毎日体重を測る
おわりに
とまぁ、こんな感じで雑に振り返ってみたり抱負を述べたりしましたが意味があるかどうかは今後の自分次第だけど良い機会にはなったので引き続き今を一生懸命生きつつ、ほどほどに頑張りたいと思います！
2月には納車、6月には4人目となる子供が産まれる予定(!?)なので今年もイベント目白押しな予感！！
Azure Kubernetes Service関連で役立ちそうなリンク集
色々教えてもらったので備忘録
Microsoftラーニングパス
製品欄のAzure Kubernetes Serviceにチェックをいれた状態のURL
AKSクラスターのB/Gデプロイ
API の破壊的変更時に Azure Kubernetes Service (AKS) クラスターのアップグレードを自動的に停止する
非推奨のAPIの使用を確認できるKubernetes API deprecationsが便利そう
AKSリリーストラッカー
AKS は、すべてのクラスターと顧客に影響を与える一連の修正プログラム、および機能とコンポーネントの更新プログラムを毎週リリースします。 ただし、これらのリリースは、Azure の安全なデプロイ プラクティス (SDP) により、最初の出荷時点からすべてのリージョンに展開されるまで最大 2 週間かかることがあります。 お客様のリージョンが特定の AKS リリースの対象となっている場合にそれを把握することが重要であり、AKS リリース トラッカーは、これらの詳細をバージョンとリージョン別にリアルタイムで提供します。
AKS CHANGELOG
定期的に読むと良さそう
AKS Release Note
日本語化されているものがオススメ
AKS B/GデプロイのTerraformサンプルコード
MS真壁さん作
Azure Kubernetes Services のトラブルシューティング に関するドキュメント
KubernetesにArgoCDをセットアップする
とりあえずAKSのセットアップができたのでArgoCDをデプロイしてみる
とはいえ基本的には公式に記載されていることをするだけでデプロイできた（k8sすごい）
$ kubectl create namespace argocd $ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
お手軽に接続して確認するためにPortFowardingを実施
$ kubectl port-forward svc/argocd-server -n argocd 8080:443 Forwarding from 127.0.0.1:8080 -> 8080 Forwarding from [::1]:8080 -> 8080
https://localhost:8080/ へ接続するとArgoCDのログイン画面が表示されることを確認
argocdコマンドで初期パスワードを取得する
$ argocd admin initial-password -n argocd XXXXXXXXXXXXXXX ←ここに初期パスワードが表示される This password must be only used for first time login. We strongly recommend you update the password using `argocd account update-password`.
先ほど取得したパスワードとadminユーザーを入力してログインできた
