駆け出しプラットフォームエンジニア1年目

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

プラットフォームエンジニア1年目の2020年を振り返ります。大変だったこと、うれしかったこと、キャッチアップを加速させるためにやったことなど。

2020年

異動

2020年に、マイクロサービスを開発するためのプラットフォームを開発・運用するチームに移りました。

Software Engineer, Microservices Platform

2019年までは、そのプラットフォーム上で稼働するマイクロサービスを開発・運用していました。2018年9月の入社当初、GCP、Kubernetes、Goの業務経験がなかった状態で設計〜リリースまでを担う中で、プラットフォームが提供する機能に大いに助けられました。

一方で、サーバーレスなテクノロジーが好きだったり、Kubernetesを学ぶ中でKnativeに出会ったりしたことで「マイクロサービス開発者から見たプラットフォームの利便性」はもっと向上できるのではないかと思い、Microservices Platformチームに参加させてもらうことにしました。

1年目にやったこと

列挙するとつぎのようプロジェクト・役割に携わりました。

  • オンサポート（複数回）
  • Istioワークショップ
  • Network Policyの導入
  • Disaster recoveryテスト
  • リライアビリティ強化

6週間毎に、担当が変わります。

オンサポート

最初はオンサポート（とオンボーディング）でした。マイクロサービス開発者から寄せられるサポート依頼に対応します。オンボーディング観点では、アーキテクチャやリポジトリなどには馴染みがあったので、KubernetesクラスターやTerraform周りのオペレーションや、プラットフォームチームが開発・運用しているコンポーネントのキャッチアップが中心でした。

Terraformは何も知らなかったり、KubernetesのオペレーションはマイクロサービスのデバッグやCKADで出てくる範囲くらいしかわかりませんでした。そのため、

検証環境でやるのを見せてもらう -> 開発環境や本番環境でついてもらってやる

というペアオペレーションが多かったです。フィードバックも毎日夕方に1on1してもらって、改善の日々でした。

マイクロサービス開発時に自分もわからなくて頼っていたエラー対応が、チームを移ったからといって即座にわかるようになるわけがありません。間をおいて何度かオンサポートを担当したり、他のプロジェクトに取り組むなかで理解を深めました（今もなお。アサインに配慮を感じつつ）。

Istioワークショップ

Istioワークショップは、Istio何もわからんの状態からいろいろキャッチアップして、マイクロサービス開発者向けに「サービスメッシュとは何か」を話したり、マイクロサービスのテンプレートとなるマイクロサービスで実際にIstioの機能を試すハンズオンセッションです。

外出自粛直後の3月の開催だったので、慣れないながらもSlackでコミュニケーションしつつ、Google Meetでスライドやターミナルをシェアしながらがんばりました。マイクロサービス開発者目線では、どんな便利なプラットフォームの機能も、機能開発が忙しいときには導入やキャッチアップ自体がかなりのハードルです。こういう試みは大事と思いつつ取り組みました。

つぎの本、Udemyの講座、登壇が特に役立ちました。

ドキュメメントは読みますが、最初にDemoを含む動画で概要をつかむと捗りました。

Network Policy

Network Policyの導入は、KubernetesのNetwork PolicyをTerraformモジュールも利用しつつマイクロサービス開発者が利用できるようにするものです。

今回は利用しない機能、デフォルトで有効にすべきポリシー、サポートするユースケース、段階的な移行方法などを議論しながらDesign Docを書きました。議論のスコープに、Network Policyに限らずプラットフォームコンポーネント全体に影響する事柄もあったことから、ｼｭｯと決めきれず難しさを感じました。しかし、ユーザーインターフェースとしてのTerraform variableや、設計議論の進め方など、学ぶことが多かったです。

また、導入にあたり希望マイクロサービスのベータテストを行い、フィードバックをもらって改善するプロセスなどは「プロダクトとしてのプラットフォーム」を強く感じました。

会社のテックブロクは書きませんでしたが、技術的にはつぎの記事のようなイメージです。

Terraform Kubernetes Providerとkindで試すNetworkPolicy

こういうユースケースのテストにこそTerratestを使ってみたかったです。最近出した本中のモジュールで、はじめて使いました。

Disaster Recoveryテスト

Disaster Recoveryテストは、GCPのTokyoリージョンが利用できない状態になったら…を想定して、すでに用意していたDisaster Recovery計画に基づきOsakaリージョンでサービスを一時的に立ち上げるものです。

クラスター内のリソースバックアップにVeleroを利用し、復旧用スクリプトを用意するなどしました。チーム横断的にとりくむプロジェクトだったので、あえて議論の枠を準備したり、定例や振り返りをリードしてみたりに挑戦しました。

リライアビリティ強化

リライアビリティ強化は、Datadogのモニター、ダッシュボードなどを見直たりしていい感じにアラート対応できるようにする取り組みです。

数百あるDatadogのモニターをすべてリストアップし、Playbookがないものを洗い出して追加したり、よくアラートが鳴るものの原因を調査したり、絶賛年末大掃除みたいな感じでした。

メンバーが増えて、再現可能な状態でオンコールにオンボーディングするには、適切な閾値でアクションのとれるアラートが鳴るのは大前提です。

その他

インターンメンバーの面接・メンターも担当しました。これまで、中途メンバーの面接やメンターはやったことはあったものの、インターン関連でははじめてです。

これがすべてです。

メンターという形ではなくても、プロジェクトのリードとして新しく入ってくる方のサポートをする機会もたくさんありました。学びの機会にあふれています。

キャッチアップとアウトプット

もちろん、業務中も必要なキャッチアップ時間やサポートはありました。しかし、僕は闘争する民族なので、これまでもやっていたプライベートOKRで四半期毎に身につけたいことを決めて取り組みました。キャッチアップすべきことは無限にあるので、「この四半期はこれ以外はやらない」をはっきりさせる意味合いが強いです。

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

2019年10〜12月の振り返りと2020年　〜YAML Engineerとしての闘争〜

2020年1〜3月ふりかえり　〜HCLエンジニアとしても闘争〜

2020年4〜6月ふりかえり　〜より抽象的なプラットフォーム仕草を身につける〜

2020年7〜9月ふりかえりと10〜12月OKR 〜プラットフォームエンジニア設計譚〜

2020年10〜12月ふりかえりと1〜3月OKR 〜旗を立て始める〜

資格

1年と少しで、KubernetesとGCP関連の試験をいくつか受け合格しました。

  • 2019/12: Certified Kubernetes Application Developer (CKAD)
  • 2020/3: Certified Kubernetes Administrator (CKA)
  • 2020/6: Google Certified Professional Cloud Architect
  • 2020/9: Google Certified Professional Cloud DevOps Engineer
  • 2021/1: Google Certified Professional Data Engineer

Kubernetes関連のものは、テストでも準備でも実技不可避だったので取り組みました。Kuberneteクラスターのバージョンアップなどでかなり役立ちました。

GCP関連のものは、それぞれ動機が異なります。Cloud Architectは、Terraformの本を書こうとしたらGCPの基礎理解がなさすぎて書けなかったからです。執筆を一時中断し、あわてて『Official Google Cloud Certified Professional Cloud Architect Study Guide 』を読みました。模試Webサービスつきなことや、物心ついてからクラウド概論に触れてなかったこともあったりで役立ちました。文章に品があって良いです。

Cloud DevOps Engineerは、SREの原理・原則を理解したかったタイミングで確認テストとして受けました。テキストは『サイトリライアビリティワークブック ―SREの実践方法』です。

Professional Data Engineerは、GCPのDBまわりをざっくり知りたかったのと、Terraform本にデータパイプラインの例を足したかったので勉強しました。安定の『Official Google Cloud Certified Professional Data Engineer Study Guide』が教材です。

極論資格として取得できてなくてもよかったですが、どの時期に何を勉強していたかがわかりやすくていいですね。

執筆

1年で3冊の本を執筆・改定しました。毎Q締切があってきつい1年でしたが、取り組んでよかったです。

Knative本は、同僚に「なぜIstio（VirtualService）を使わずにKnativeはトラフィックスプリッティングのような機能を実現できるのか」と質問されて答えられなかったのがきっかけで調べることにしました。ちょうどIstio関連のプロジェクトに取り組んでいたタイミングで、ネットワークまわりをいろいろ調べられました。

Terraform本は、GCPでTerraformを体系的に学ぶための情報がないという問題意識に基づき書きました。

特にオンサポートをやる上では、Terraformのデバッグは必須です。また、何かプラットフォームとして機能を提供する際には、Terraformモジュール設計が大体必要です。自分が実務に取り組む前に知っておきたかったことをまとめました。

さらに、マイクロサービスの開発者にとっても、有益な情報であると考えました。たとえプラットフォームがモジュールを提供しても、マイクロサービス独自に利用するリソースについては、現状Terraforを書かなくてはいけません。エラー調査をプラットフォームチームに依頼する際も、大まかな仕組みや原因がある程度わかった方が容易です。プラットフォームのエンジニアとしては、困ったら頼ってほしいと思いつつ、マイクロサービス開発者としては、頼っていいものなのか自分たちでなんとかできるものなのか切り分けできたかったという思いがありました。そういうものを意識しなくても、開発に集中できるプラットフォームを目指しているのは言うまでもありません。

（前年比）業務に密接に関連した執筆は「あ、これ昨日検証したやつや！」の連続で、本業に活きていている感がすごかったです。

ついでに、売上で椅子が得られたりしたのでとてもよかったです。

本

7〜9月のKRのひとつに掲げていたのが「学び方の改善」です。

学び続ける生き物は、その学び方を改善することで得られるメリットが計り知れないほど大きいです。

『エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする』を読んだり、チームの人のおすすめリストを読んだりしながら自分なりに読書リストを作って進めています。意識的にOKRに関連させるようにしています。これら以外は読まないというわけでもないですが、読むのが速くないので特に大事なものに絞る必要があります。

Platform Engineerへの闘争🐸

読み終わった本。

こういうのも親身に相談に乗ってもらえるので、安心して闘争できるのがうれしいです。

複業

サーバーレスコミュニティのつながりもあり、複業にも取り組みました。以前いったんは始めたものの結局タイミングやフェーズ合わなかったり、執筆や寄稿もある意味複業とは思いますが、案件に入っていくのは初めてです。

いつか一緒になにかできたら…と思ってた方々と一緒に仕事できてよかったです。一方で、あまり案件に深く入れないまま終わってしまったので残念でした。SlackでGCPの質問に答える係を3ヶ月担当しました。

フロントと認証・認可まわりは課題っぽいです。

2021年

2021年のことも書こうとしたのですが、思ったより長くなったので別記事にします。

業務的には、引き続きPlatform Engineerへの闘争を進め、プラットフォームエンジニアとしての運用ももっと楽にできるようにしたり、マイクロサービス開発者向けにサーバーレスで想起されるような体験を提供していきたいです。

Tweet
Share
0 Shares

3コメント

  1. ピンバック: 2021年プラットフォームエンジニア2年目のふりかえり – DoorLog
  2. ピンバック: 2021年プラットフォームエンジニア2年目のふりかえり – DoorLog
  3. ピンバック: 2022年プラットフォームエンジニア3年目のふりかえり – DoorLog

コメントを残す

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