2022年プラットフォームエンジニア3年目のふりかえり

by ·0件のコメント
Tweet
Share
0 Shares

2022年は、プラットフォームエンジニアリング的なことは行いませんでした。一方で、プラットフォームエンジニアリングを行う上で大事なSREプラクティスの実践や、社内他サービスが横断的に利用し、社外のユーザーにも機能提供するサービス開発、種々のデータ移行やインフラのメンテナンスなどの運用経験が増しました。

その意味で「プラットフォームエンジニア3年目」として振り返るかどうかは迷いました。しかし、大きく目指す方向性や提供したい価値は変わっていない以上、同じ枠で振り返った上で軌道修正すべきならする、方向性自体を変える必要があるなら変えるべきと思い、このタイトルで書くことにしました。

役割の前に、組織における課題が存在します。そのため、特定組織を前提としない一般的な役割に合致した動きをしたかどうかで良し悪しが決まるのもではありません。提供価値の多寡とも別軸です。その上で、ここで言及する「プラットフォームエンジニア」はこの記事で触れられているようなものを意図しています。

チームトポロジーでいう「プラットフォームチーム」とも重なる部分も多いですが、軸や出自が異なります。

過去分

2022年

3年目にやったこと

  • Cloud SQLのSpanner移行
  • 認証サービスの開発・運用
  • fastly、GKE、その他GCPのサービス、Terraformなどを利用したサービスインフラの開発・運用
  • アサイン調整に利用するスキル、アサインなどメンバー情報の可視化ツールやデータパイプラインの整備

Cloud SQLのSpanner移行

1サービスの移行を終え、中断しました。あとは頼んだAlloyDB。

認証サービス開発・運用

SREとして信頼性やインフラに関わる部分だけという形ではなく、プロダクトとしての認証サービスのスクラムのスクラムマスター兼開発者として参加しました。認証サービスは、ユーザー接点のあるプロダクトしての顧客価値検証的な側面もある一方で、サービス横断的な必須基盤として側面が強いです。継続的・安定的な運用が不可欠な特性が強い分、開発・運用不可分（切り出された運用だけ請け負う形式は苦しい）だと改めて感じました。SREのプラクティス実践においても、サービスのドメイン理解は必須です。

前職では、マイクロサービスプラットフォームを開発するチームに異動する前に、決済関連のマイクロサービスをいくつか設計、開発、運用していました。当時と比較して、持続的に信頼性高く運用していくためのプラクティスの理解が増し、打ち手も増えたように思います。改善の余地はあるけれど、継続的な改善に取り組めるイメージや周囲の理解があるのが何よりです。

ただ、自身の認証（・認可）ドメインの理解度がなかなか高まらず、プロダクト開発者としての動き（プロダクトロードマップの議論、利用プロダクトのサポート、ドメイン観点のレビュー）が鈍かったり、コード全体の雰囲気の理解度も高まらず「オーナーシップを持って開発・運用している状態」には程遠い（or 表面的な反応はできても本質的な打ち手を出せない）という反省やもどかしさがあります。言語的な観点では、「Goに入りてはGoに従え」を実践したいのはどの組織でも感じるし、自分にもやっていけることがありそうです。スクラムマスターとしての動きも、一般的なことをざっと復習して経験、振り返り、改善に徹するにとどまり、よいプラクティスを主体的に収集、検討、導入するには至りませんでした。

諸々を経てやることを絞ってみたものの、絞った中でも取りこぼしが多かったというのが実感です。

より具体的にはつぎのようなことに取り組みました。

  • SLI/SLOの導入
  • PrometheusのカスタムメトリクスやGrafana、Cloud Monitoringを利用したオブザーバビリティ強化
  • Firebaseからのデータ移行
  • GoとNext.jsを利用した機能開発
  • fastly WAF導入

サービスインフラの開発・運用

fastly、GKE、その他GCPのサービス、Terraformなどを利用したサービスインフラの開発・運用を行いました。メディア露出などの事前にタイミングがわかる負荷の対策、アプリケーション開発者からの問い合わせ対応やサポート、メンテナンス、問題調査などが主です。影響範囲の広い基盤設計や、Kubernetesエコシステムの調査、検証などにはあまり触れなくなりました。

サービスインフラ（システムアーキテクチャ）は理論上変更できるものの、いわゆる「ハードパーツ」です。アプリケーション以上に運用が人員的にボトルネックになったり、機能が見えづらい分構造の改善に投資しづらく、組織文化によってはハードパーツ化に拍車をかけます。その意味で、技術的意思決定時に何かを取り何を取らなかったか、取らなかったものが問題として顕在化するタイミング、その意思決定の記録を残すこと、取りたいものに対して極力シンプルなアーキテクチャで運用負荷を下げることの重要性に対する認識が深まりました。限られた工数の中でそういうものに取り組んでいたり、組織の認識も変わりつつある状況だったりで尊いです。

fastlyのTerraform providerの（破壊的）バージョンアップや、Cloud SQLからの移行含めSpannerまわりの大小データ移行では、公式に提供されている方法・ツールでは無理があったところ、各種OSSに助けられ安全に実行できた。別記事にします。

メンバー情報可視化

組織開発文脈で、アサイン調整などに利用するスキル、アサイン、過去担当プロジェクトなど、メンバー情報の可視化ツールの整備を行いました。先人が整備してくれた仕組みを活用させてもらい、外部SaaS、メンバー入力情報など、さまざまなデータソースを1箇所に集約するためのデータパイプラインに触れました。データプラットフォームは領域的に近いようで直接は触れてこなかったので、一連のデータフローを眺められたのはよかったです。

複業

かなり時間的な制約が大きかったり、休んでいる期間も長かったりした分、解くべき課題の選定、設計をしっかりやって短期間集中して取り組みました。

  • オブザーバビリティ
  • SLI/SLOと運用
  • マイクロサービスプラットフォームのイシューマップとロードマップ作り
  • Cloud Runネットワークまわり
  • Dialogflow CX開発フロー整備

オブザーバビリティ

マイクロサービスプラットフォーム開発において、2022年1〜3月はマイクロサービスの死活監視の概要がわかるダッシュボードと、開発・運用のためのログ、トレーシング、エラーレポートが関連付けられている状態を目指しました。

複業の中でおいたOKRは、メンバーの助けを借りつつ一通り構築し終えました。OKRはつぎのようなものでした。

  • O1: 単一のリクエストIDでマイクロサービスのメトリクスを関連付けて自由自在に調査できるようにする
  • KR1: 各サービスの稼働状況がひと目でわかるようにする
  • KR2: リクエストIDでログをマイクロサービス横断でフィルタリングできるようにする
  • KR3: エラーレポートからリクエストIDが取り出せるようにする
  • KR4(option): 単一のリクエストがどのマイクロサービスでどれだけ時間を要したか分析できるようにする

複業においては細かいタスクを渡してもらうよりも、大きな課題を渡してもらった上でADRを書きながら課題調査・精査、PoCし、議論を収束させ実装に向かう流れを腰を据えてやっていくスタイルが好きでした。

このOKRに関しては、以下の2つのADRで提案・議論する形で進めました。

  • 分散トレーシングの技術スタックとTrace ID選定
  • 構造ログの構造とライブラリ選定

SLI/SLOと運用

こちらはObjective下のアラート対応の仕組み化というKRをもち、つぎの受け入れ基準を満たすようにやっていくというものでした。

  • Sentryのエラー対応フローがアプリケーション開発チームで運用されている
  • xxx、yyy、zzzサービスのSLI/SLOが定義されている
  • SLOを脅かす状態にある可能性があるときに通知される
  • アラートを見たオンコール当番が何をすべきかわかる
  • （stretch）緊急のエラーがオンコール当番に電話通知される

SRE本を振り返りながら、以下2つのADRを経て進めました。いずれもどのチームがオーナーシップを持つのか、プラットフォームチームはどうサポートすべきかの議論からでした。立場上、自分がサポートするというのは限定的でした。

  • Sentryの運用方針
  • SLI/SLOの導入

マイクロサービスプラットフォームロードマップ作り

以下がある中でそれらがどう関連し、どうロードマップを作り、それを元にどうjob descriptionを作っていければよいかを考えるためのドキュメントを書きました。

  • チームミッション、ビジョン、バリュー
  • OKR
  • 開発サイクルとアーキテクチャ上のコンポーネントベースでのイシューマップ
  • イシューマップに典型的なソリューションと取組状況を追記したもの
  • 開発者目線の課題感

プラットフォーム作りで何を掲げるにしても、開発者が普段の開発において感じる課題が解決されてなんぼというのを改めて考えました。

Cloud Runネットワークまわり

Cloud Runを使う分には、ネットワークであれこれ考える必要と思い込んでいました。しかし、VPC関連の設計や接続先・接続元次第では考慮すべきことだったり、とれなくなる選択肢があったりするというのを学びました。

Dialogflow CX開発フロー整備

チャットボットのバックエンドサービスのような、複雑なワークフローを含むサービスをどう複数人・複数ステージ（dev、stg、prd）で開発・デプロイすべきかという課題に取り組みました。その辺りをサポートするDialogflow CXの機能が限定的だったり、一般的なGitOpsと噛み合わない設定モデルの中で、いろいろ検証するのは面白いテーマでした。

まだやりきってないのと、現段階でそこまできっちりした管理は求められてないのでタスクはタスク、研究は研究で分けます。

プライベートOKRとアウトプット

業務とは別に、プライベートOKRで四半期毎に身につけたいことを決めて取り組みました。取り組みたいことは無限にあるので、「この四半期はこれ以外はやらない」をはっきりさせる意味合いが強いです。

OKRは、各記事でなぜそれが達成したいのかや、どの程度達成したのかなどの振り返りと合わせてまとめています。

学業

大学院の振り返りはnoteに書きました。

Georgia Tech OMSCS 1年目総括

出願の動機（本音）は、「もしいま働かなくてもいいとしたら、コンピューターサイエンスをしっかり勉強してみたい」でした。しかし、いざ履修したい科目を挙げていくと、現在のプラットフォームエンジニアリングに深く関わる分散システムの理論と実装、クラウドコンピューティングの実装、OS、コンパイラなど、低レイヤーの理解を深めるものが多いのは変わりありません。次節のプライベートOKRで目標に据えるのはもちろん、プラットフォームエンジニアリング上も重要なものとして位置づけています。

これまでと異なる形での交流も、刺激があってよかったです。

資格

無資格。GCPの資格がいくつか失効したり、Kuberentes関連もついに失効し始めています。取り直す気持ちはあまりないです。

執筆

大学院の夏学期と秋学期の間をぬい、既刊の改訂版を出せました。昨年までは、中長期的に詳しくなりたいものを実践・検証を踏まえて体系的に整理し直すというモチベーションで本を書いてきました。しかし、改定だけでも当該期間の土日をほぼすべて費やしたので、やり方を考え直さないと未知の分野に踏み出せないと課題に思っています。組織的な知見はないが、確実に投資したい領域として体系化したい、イネーブルメントもしたいという文脈の中で取り組めるとよいですがそれは奇跡ですね。

技術書典13で『Google Cloud Platformで学ぶTerraform 』基礎編・実践編の第2版を出します #技術書典

技術書

Platform Engineerへの闘争🐸

リストの中で読み終わった・読んでる本。

登壇

無登壇

OSS

いろいろ助けてもらいました。目の前の課題解決を急ぐ上では、活用させてもらうのが局所解です。たとえそうでも、立てられているissueのサポートをしたり、よりよい形で提供できるなら自分で作ったりしたいですね。悲しくなります。

総括

転職と大学院生生活が同時に始まる中、果たしてやっていけるのかという不安から始まった1年でした。両立という観点では、振り返りでも書いたとおり、今年はなんとかなったものの来年以降はこのままでは厳しいですね。エンジニアとしては、触れるタイミングが来るとはと思っていなかった認証サービス開発に触れられたのは幸運でした。

プラットフォームエンジニアの文脈では、年末に人と話していると自分は特定の形のプラットフォームを作りたいというわけではなく、「どういうフェーズであれ、なにかを実現したいときにソフトウェアを変更し続けられるよう、アーキテクチャ・技術的に妥当な判断をトレードオフを加味してし続けられる、それを実現する技術力もある」ようでありたいと思っていることがわかりました。また、事業の成長に必要なことはやるという大前提のもと（あるいはそれと関係なく）で、エンジニアとして好きなこと・嫌いなことは何なのかが見えてきた年でした。強み・弱みや伸ばしたいところ・克服したいこともその辺りに関係していそうなので、プライベートOKRに盛り込んでいきます。

2023年

1年単位で目標と立てることは自分にとって大きな意味をもたなかったので近年はやっていない（方向性を持ち、3ヶ月単位の計測可能な目標を定め、振り返り、方向性に問題があれば修正してつぎの3ヶ月単位の目標立てることが有意義）です。それでも敢えて掲げたいのは、1年後振り返ったときにこれはやりきった、これはワシ（自分が一定以上貢献したと自分で感じられる限りワシら）が育てたと思えるものが一昨年以上に大きくなっていることです。あと、言語化したくないことでも、外に出すべき・出さないべきは別として、した方がよいというのは指針として持っておきたいです。

Tweet
Share
0 Shares

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です