SREに関する雑談 bosyu#3 キャリアの幅の広げ方とインフラを"ちゃんとする"までの道筋

こういう bosyu をやっています！

bosyu.me

今回は Web Engineer の方に対して、キャリアの進め方に関する話と、インフラの信頼性をどうちゃんとしていくかという話をしました。

Web Engineer がインフラ領域に幅を広げるためには

逆に僕は Production で動く Application コードを書いた経験は乏しく、かつフロントエンドに関してはほぼ未経験みたいなもんなので、すごいなあと思いつつ。

相談された方はバックエンドとフロントエンドを両方やるエンジニアで、現在はスタートアップで少人数で働いているとのこと。

技術的な賞味期限を考えると低レイヤーを学んだ方が賞味期限が長いのでやりたいと思うが、その広げ方、深掘りのしかたを悩んでいる、とのことでした。

スタートアップにいるということなので、すぐバリューを出せるところ（得意なところ）をやりがち
- 例えば現在の状況でインフラ領域をやる、となると生産性はどうしても落ちてしまう
- 少人数であればそれをサポートする組織体制を期待するのもきっと難しい
chaspy はどうしているか
- ごもっともだと思うが、自分はいい意味で（？）低レイヤーとか、アルゴリズム、高度なプログラミングなどは諦めている
- というより、現実にぶつかる問題ベースで、それに関連することを都度学ぶしかないと思っている
- もちろん先取りしてそれらの知識をつけておけば、その解決速度が早くなることは承知しているものの、いつ役に立つかわからないのも事実
- 現在は投資対象を英語と直近で役立つクラウド、SRE、チームリーディングなどにしているため、現実時間でその先回りの投資的な勉強は正直できてない
- ただ、その課題感はすごい分かるし、長期的には自分もどうにかしないといけないと思っている。。。
最近 chaspy が業務で Golang を書いている事例
- Go は SRE にとって必須教養だと考えている。
  - 使う OSS も Go で書かれているものが多い。upstream のコードを読んだり、パッチを送ったり、プラグインを書いたりできたほうが絶対良い
  - ある程度大きいプログラムは bash で書くといろんな面でつらい点が増えてくるので、そういう点でも bash 以外のプログラミング言語のほうが良い
- チームメンバーに Golang が得意なメンバーがいるので、彼らに活躍してもらうために、チーム内の標準を Golang にしようと合意をとった
- その結果、自分もその機会に恵まれた
- 実際の問題解決と学習対象を結びつけた 事例だったと思う。こういうことが増やしていけるといいよね
とはいえ、現在の状況で、実業務を通じて学習していく機会を作っていくのはきっと難しい
- 自分がとけそうな課題を発見するのが難しい。それが1日でできるのか、1週間かかるのかの判断がある程度経験ないとできない。
- 適した課題が見つかったとしても、それを独力でやりきる胆力も必要
課題意識の解像度をもう少し高めたほうがいいのでは
- 「低レイヤー」と見ている、呼んでいるものの中で、何を獲得したいのかを言語化する
- 今だと「フロントエンドやりたい」と同じ状態になっている
- 学習内容の詳細化、言語化なら chaspy も壁打ち相手で役立てると思うのでまた

みたいな話をしました。すごい難しいですよね。

自分も今は「わけのわからない焦り」みたいなのはなくなって落ち着いている一方で、長期的なキャリアを考えた時に、深い・低いレベルでの技術の理解、だったり、フロントエンドを含めたアプリケーションコードを書いた経験の薄さみたいなところは課題に思っているので、すごいわかります。

まとめると、

今の領域と違う分野を業務外で学習し続けるのは時間的にもモチベーション的にも厳しい（できるひともたまにいるが、すごすぎると思う）
業務での実際の課題を、自分の学習と結びつけるような環境にいろんな方法でやっていけると良さそう
- そのためにはもう少し学びたいことの解像度をあげたり
- メンバーにこの問題意識を共有して知ってもらったりするのが良さそう

という感じでした。いい話ですね。

インフラを「ちゃんとする」ための道筋

背景
- スタートアップということで、最低限のインフラで動くものをスピード感を持って作るということが非常に重要
- インフラはまだプロダクションに出していないということもありまだ後回しになっている
- VPS に docker-compose で up しているだけ
- 課題感だけ漠然とあるが、どの順番でどこから手をつければいいか？

ということで、これ実際に面接とかで使うと面白いんじゃない？ってぐらい面白い課題でしたw

コンポーネントやトラフィックフローが描かれた図を見せてもらいながら、以下のような候補をあげました。

データをなくさないこと
- データなくなったら困りますよね（それはそう）
- データの定期バックアップをする
データベースの管理
- 運用にコスト避けないならなおさら外部に持って Managed にしたほうがいい
- スケールアップ、スケールアウトが容易なものにしておいたほうがいい
リリースエンジニアリング(CD)
- 今は少人数だから ssh してコードを pull するでもいいけど、遠くない将来コミュニケーションコストがしんどくなってくる
- あとそんなに難しくないので、投資対効果が高いので早くやるのがよさそう
メッセージング基盤
- これもセルフホストは結構しんどいんじゃないか
- Managed を検討したほうがいいと思う
- データベースと同じぐらい自分で面倒みたくない
Logging
- 障害対応時に調査できるかどうか
- これも Papertrail / Stackdriver Logging とかの SaaS がある
- fluentd から投げるだけならそこまで難しくないと思う
可用性
- 少なくともフロントの Reverse Proxy が落ちるとすべてサービス死ぬと思うので、そこの可用性確保が最優先
- これを考えると同時に現在の状況からどのクラウドで、どういうアーキテクチャを採用するかを考えないといけないと思う
- 現状の人数なら Kubernetes は too much かも詳しいひと、モチベーションがあるひとがいればいいけど
- PaaS でできるならそれが楽 heroku は最高
- AWS, GCP などのクラウドを使うならまたそれだけで大きなトピックになる