日記マン

動画広告プロダクトしてます。Go, Kubernetesが好きです。

2019年振り返り

明けましておめでとうございます。あとで振り返る用に。

仕事

新卒入社の会社で3年目。
プロダクトのコアシステムとなる広告配信サーバをリライト・リアーキテクトした。
最初1人で計画・実行し途中からメンバーを集めテックリードのポジションになった。

  • 認知コスト軽減のために、リーダブルなコードへリファクタリング。(PHPからGoへ移行)
  • 変更の安全を証明するために、テストコードの導入。(TDD)
  • Observabilityへの取り組み、監視ダッシュボードの作成 (Instrumentation, Prometheus, Grafana)
  • RPSやQPS、レイテンシ分析、IOサイズなどワークロードの把握 (パフォーマンスモニタリング)
  • GoのGCの動きを理解・観察 (ランタイム知識・監視)
  • プロダクション環境アプリケーションのプロファイリング (pprof)
  • 継ぎ足し続けた機能を整理するために、実績を調査しビジネスサイドと折衝交渉 (調査)
  • プロダクトの現状理解と論理分析して意思決定層・メンバーに説明 (ティーチング・コーチング・社内LT)
  • オペレーションの自動化と属人性改善のために、CI/CDの導入 (Kubernetes, Cloud Build)

なぜやるか・どういう問題が起きてるか、なにができるか、どこから手をつけ始めるか を意識しながら(というのは半分嘘で前半はHowに拘りすぎた。反省)取り組んできた。
リライト・リアーキテクトの付加価値として、
リリースと監視の民主化 を掲げProductivityの向上に取り組んだ。
対象はシステムのみならず業務プロセスレベルまで広げ組織全体に影響する必要があった。
いくつかはブログにアウトプットできたかなーって感じだけど、日が経って読み直してみると今となって考え方が少し変わってきていることもある。
その辺のアップグレードしたものを2020年はアウトプットしていけたらと思う。

リーダブルなコードへのリファクタリング

例として、「リーダブルなコードへリファクタリングした」はどう動いたか。
PHPを継続せずにGoを採用した。自分自身、とある案件で実務採用経験があった。
PHPからGoならば学習コストも高くなく、ツールチェーンもすぐに手に入り、コミュニティも強い。
「型」による静的検査の強力さを社内に伝えた。
また広告配信サーバのパフォーマンス要件的にもGoのgoroutineと非同期I/Oを上手に扱うランタイムはマッチしていた。

GoはネットワークI/Oをどう実現しているか - 日記マン

しかし、全てのコードをゼロから書き直す、という工数コストを払う必要があった。
開発初期からメンバーにアサインしてもらい、Goの作法を習熟してもらった。
この時、アサインメンバーを限定する、という方策にもでた。
当時、配信サーバは暗黙的にアサインメンバーが社内エンジニア全員だった。
それをチームを構成しそのチームメンバーでコーディング・メンテすることにした。
これは アサインメンバーのスキルを一定に底上げする・理解してもらう・ルールを制定する 必要があるが、それが全員となると難しいと判断したためである。

個人活動

個人活動としてはGoのコードを静的解析しPlantUMLコードに変換するツール goumlOSSとして公開した。

GitHub - kazukousen/gouml: Automatically generate PlantUML from Go Code. ★54

AST解析自体はじめて取り組んだので、新たな世界をひらけたなーと実感。
ツールの開発だけでなく、使っているソフトウェアに対してPRやIssueを送ることも少しずつ増えてきたので、2020年も続けたい。

ブログは月1本のペースを目標にしていて達成できた。
DDD, Go, Kubernetes, Observability を調べる・使う過程で学んだことを主にアウトプット。 反応が多かった記事もいくつか。

GoのコードからPlantUMLコードを生成する静的解析ツールを作っている - 日記マン

ドメイン駆動設計のドメイン駆動とはなにか - 日記マン

今見返すとDDDといってもちょっと戦術的デザインパターン寄りな感じ。
今ではDDDは戦略的設計時点こそ重点を置いて考えている。

インプット

上半期はDDDやOOP筆頭にアプリケーションアーキテクチャが多かった。
下半期はKubernetesやパフォーマンス監視など。

はてなブックマーク - i101330のブックマーク

Observabilityを計装してメトリクスを眺めサービスの状態を把握する、という一連の流れを実施できている。
方法論を Brendan の 詳解システムパフォーマンス で学べたのがとてもよかった。

詳解 システム・パフォーマンス

プロダクトや組織の課題を理解・分析・選択するために、
論理的な基盤を構築することはとても重要だと痛感した。
その手の入門書として 問題解決の全体観 がとてもよかった。

問題解決の全体観 上巻 ハード思考編 (知的戦闘力を高める全体観志向)

2020年の目標

  • 社外登壇
  • 資格CKADの取得
  • 使う側だけにとどまらず、OSSへの貢献などを通してソフトウェアを作る側へコミットする。特にGo製/CNCFのツール。
  • アプリケーション、Linux、各リソースのパフォーマンス分析のスキルを身に着ける
  • フロントエンドも書けるようにする

OSS活動・社外登壇などを通してコミュニティへの貢献できることがあればしていきたいし、自分や組織をプレゼンスするスキルを身につける。

まとめ

サーバサイド・インフラを中心に成長はしてきてるかなと思う。
KubernetesやPrometheusやruncを利用するにあたってコードを読み込んだりするのも面白かった。
SRE方法論やDevOps思想へも強い共感を覚えて考え方のベースになってきている。

またビジネスへの関心も強まったので、ビジネスについても勉強を深めていきたい。
今年の最大の反省点としてプロダクトのビジョンがそもそも曖昧な設定の状態でリプレイス計画を実行したことだ。
次第に求められるようになってから自分も事業・組織のビジョンについて考えるようになったが、まず最初にビジョンの設定を意思決定層と対話すべきだった。
意思決定層・プロダクトオーナーには確固たるビジョンを描いてもらい、自分はとにかく実績データをもとに根拠あるビジョナリーとして動くべきだった。
それでWhyを練り上げてからHowを実行すべきだったが、上半期はHowから手をつけ始めてしまい、結果的に計画の遅れや後戻りが発生してしまった。
このようなことがないように、プロダクトオーナーと真摯に向き合い、自分たちのビジョンを描き、その戦略をストーリーテリングできるまで熟成してから、
作業に取り組むことを心がけていくことを学んだ。

セカンドキャリアとして転職を検討しているので、魅力的なプロダクトのある会社で自分が役に立てそうなポジションがあれば是非貢献したい。
目指すポジションとして PdM寄り・テックリード寄りどちらかはまだ決めてないが、
データを観察(収集含め)・把握・選択と実行 という当たり前の動き方をしっかりと身に付けていきたいと思う。
(昔から好奇心ベースに偏向する癖があるのでもうちょっと実利的に動きたい)