リッチウーマン・プアウーマン」ビジネスは大事で仕事には色々なステークホルダーがいるが、VPoEとして引けない部分は経営者にもはっきり言う。忖度なく、相手の立場を理解しリスペクトした上で自分の伝えたいことを要求する必要があり、それは辛い。成果のためには鬼になること。人と接することにエネルギーを使う。時にはドライに考えてやるべきことに集中すること。パフォーマンスを出すために割り切ること。他の部署との関わりが増え、そこの責任者と話すことも増えたが、エンジニアと話すときと同じノリで話すとトラブルになることが多い。バックグラウンドが違うことを認識して接することが大事。加藤様の場合これからVPoEとしてやっていくので不安について。フェーズとか規模によってマネジメントの正解も変わって来るのでメンバーには寛容に付き合って欲しい。マネージャー時代はメンバーの評価とかモチベーションアップに取り組んでいたが、今後はメンバーが思ったような成果が出ないとか人間関係のトラブルなども解決しないといけない思うので心を強く持ちたい。Professional」といった言葉をミッションとしており、社外の方でも知っているような言葉を使っているが、こういったところは広報と連携したり、評価制度に組み込んでいる。組織の中でそこに貢献してくれるエンジニアをどうマジョリティーとしていくか、全員を変えるんじゃなくどうマジョリティーにするかを重視している。エンジニアの採用をどのような体制でやっているか?エンジニア採用のマネージャーを兼務でやっている。既存採用チームのメンバーはエンジニアとして働いてきた訳ではないので、わからない部分を補完したりエンジニア採用の意思決定を担当し、実務を採用チームがやっているような分担になっている。全エンジニアとコミュニケーションをとる機会を設けられているか?今年4月からEM/PM体制と言う仕組みができて、その中でEMが1on1の機会を設けている。他色々検討している模様。MBA取得されているとのことだが、VPoEに活きているか?MBAを学んでVPoEになった。体系的に学べるところ、学校にいく必要があるため強制力があるのは良い。組織作りに興味があったが人間性が伴っていないと当時の上司に指摘され、その中でMBAに出会い、自分に向き合う機会になったのはよかった。新しい知識がつく訳ではなく、色々な本でも学べるところがあるので銀の弾丸ではないと感じる。平日はまったく時間が取れてない。CTOに教えてもったり社内での技術的な内容で知らないものがあれば調べたりはしている。休日は副業などで勉強している。時間の使い方として技術に関しては休日になってしまう。平日は仕事では12月から全くできてない。休日は学校に通っているので時間が取れていない。出会ったデザイナーの方と小さいアプリを作ってみたり、他社のエンジニアの方と交流したりすることで補っている。人の価値を上げていくことが面白いと感じているが、今は自分の組織だけをみているが米国ではバウンダリースパナー(組織や部門を超えてつなぎ合わせる役割)が注目されている。日本ではそんな肩書きはないが、やっていきたい。ある程度軌道に乗った組織に対して取り組んでいくことになるが、それまでの組織に対しても取り組んでいきたい。エンジニアリングマネージャーとして取り組んでいくが、そこから会社全体を拡大させていくことに興味をもっている。Productivity・技術戦略の取り組み前半は変化に強いインフラを目指して基盤をk8sに移してマイクロサービス化を進めたということ、中盤はそれによって起こる問題、最後にその問題を解決するために取り組んでいること、に関してお話されていた。OSへ切り替えとChef->Dockerfileへの移行を進め、2017年にk8sへ移行開始したそう。当初RoRのみだったがいろいろな言語やフレームワークを選択・対応できるようにできるだけk8sの標準のものを使って構築したらしい。k8sを全然使ったことがないのでk8s標準のものというのが全然わからない...この辺りは以下の記事にもまとまっている。BlogKubernetesを使った変化に強いインフラ――Wantedlyのインフラチームが大切にしていること:CodeZine(コードジン)MicroServiceの良いところは「技術に特化するものが作れる」、「サービスに合わせたチームができる」ということを挙げられていた。k8sは親和性が高いらしい。一方でレギュレーションをしっかり作っておくことが重要とのこと。インタフェースが明確で、バックアップがとられていて、モニタリングができて、データの一貫性を保てること、壊れないことが大事。良いところとしてはスケーラビリティがとりやすいこと、kubectlで基本的な運用可能が可能なこと、一部サードパーティー性ツールも利用しているらしい。インフラ定義はすべてyamlのManifestファイルを用いており、プロダクトごとに必ずレギュレーションに沿ったManifestファイルがあるので、ちょっと試すときなどはこれをベースとしているらしいまた、エコシステムの恩恵を受けやすいということを挙げられていた。GCP)など、k8sで動くものが増えてきている。Communityが活発なのもプラスで、Wantedlyは今後どうしていけば良いのか、という議論の中で、参考文献など出しやすく説得しやすい。することでいろいろなことが良くなるという話があるが、考えるべきことはたくさんあるとのこと。この辺りは実際に経験してみないとわからないことで、大きなサービスならではの知見がたくさんあり、マイクロサービスの経験がない自分にとっては参考になる内容が多かった。一個の変更を複数に反映する必要があるものが多数発生。k8sの問題ではなくインフラ業務としてそうなりやすい傾向もあるらしい。SSL証明書の更新とか、スクリプト化しても来年も動くか不明だったり...ELB+ACMで一回で済ませれるように、できるだけO(1)にできないか(1度で済ませられないか)を考えることが必要とのこと。エラー・インシデントのハンドリングの困難さマイクロサービスが増えてくるとインシデント発生時の切り分けが困難とのこと。MicroServiceごとにパフォーマンスが異なるためのTimeoutやリクエストが詰まるケース、サービスをまたぐデバッグ、リクエストをたたく順番によってエラーになる場合は全部のリクエストを見ることになったり、スパイクがどこからきているかわからないなど。モニタリングもできているのか?できていたとしてもわかりづらい。一時的に復旧させるにも一人二人では困難でチームでやる必要が出てくる。依存関係の問題どこかの処理が速くなったことで他が耐えられなくなる可能性。テスト等でもリクエストを送る先のサービスをケアする必要がある。不要なデータを問い合わせてくるものもある共通データサービスの成長に伴ってユーザのデータなど共通で扱うデータが出てくる。どのデータの問い合わせをどこにするのが正しいのか?といったことを考えるきっかけになったそう。知見の共有GitHubにissueとか書いてあるが、それだけだと厳しい。マイクロサービス単体で開発することはあまりなく、実際にはAサービス、Bサービス、Cサービスがあり、Aからリクエストを送ってもらわないとBが動かない...といったケースが多く、A,B,CすべてローカルPCに建てる必要がある。なるとローカルPCがスペック的に厳しくなってくる。各環境でのデータの扱い方も難しい。リストアの順番とかでデータが壊れたり...他環境が意図しないブランチで動いていたりルーティングサービス分離時にパスレベルで変更したいとき、その時都度NginxのConfigを書くのか?インフラレベルでABテストしたいときは?ネットワーク回りでハンドリングしたいときとかどうするのが良いか?Aサービス→Bサービス→Cサービスというリクエストが発生するサービスでのBサービスの開発の難しさ。リクエスト発生させずらい。Productivity),コアとなる技術基盤(技術戦略)の3つを主軸に、いろいろ取り組んでいるそう。OKRの明確化、ポストモーテムを実施したり組織として仕組化したり。明日から実践できる!運用自動化に必要な「テスト」にまつわる技術テストツールではなく、正確なインフラのテストをできるようにするかといったお話。開発/検証/QAといった環境を本番環境と同じスペック、構成のもので用意するのは非常に困難(お金面)であるが、運用系の構築スクリプトやプログラムが本番環境でも正しく動作するのかを事前に確認しておくべきで、オーケストレーションツールを使って本番環境と同等構成のテスト環境を構築してテストできるようにしよう、といったお話だった。CloudFormation)を使って本番環境を複製できるようにしておこう、というのはクラウドをベースにしていればこのアプローチはありだと思うが、オンプレミスだとかなり厳しい...ポイントとして、以下のようなことを挙げられていた。仮想ネットワークの活用、つまり本番環境と同じセグメントを持ったネットワーク環境を作ること、ホスト名に加えて、IPアドレス必要であれば合わせるなど可能な限り同じネットワーク構成として合わせる、ただしグローバルIPなど外と接する部分は異なるものとして、内部構成を一致させること。サーバのセットアップ手順を含める。Ansibleでもbashでも良いので。用心のためにリポジトリサーバやCIサーバ、ビルドサーバなども含めておく。マシンイメージを一式作成しておく。packerなどで一式作成しておき、yumなどのパッケージ管理システムでは古いpackageがだんだんinstallできなくなったりするので、自前でパッケージ管理したりイメージで保存しておいた方が良いとのこと。いうものも紹介されていた。フェーズのところでどうしてきたかというところが中心としたお話だった。資料にもある通り、0からスタートした時の事例や話というのはなかなか聞く機会がないように思う。この0->1へ変わるための取り組みが一番大事であり一番大変なところでもあると思う。目標というか方向性が明確になっているのが大事で、これがないと何をするのが正しいのかよくわからなくなって目の前の業務をやることに意識が向いてしまうように思う。増やすための攻めの設計」という2つの明確な切り口からの取り組みはわかりやすくて良い。初期フェーズでの、エンジニアリングに注力するという意識、片っ端から勉強、他社のつらみを聞く、(わからないなりに)理論を学ぶ、という取り組み、実際にやってよかったこととしての、ドキュメンテーション、スペックアップ(簡単に解決できるものをつぶす)、ルーチン・コンテキストスイッチを減らすため適用範囲の見極めに注意したうえでの使い捨て前提での自動化用コードを書くというのも、何から取り組めば良いかわからない状態からすれば道筋の1つになりそうで参考になった。紹介されてた以下の書籍も読んでいきたい。Codeといったところは自分の中でも課題となっているがなかなかうまく仕組化できていないところだったが、それがなぜできないのか何となくわかった。最初は泥臭く粘り強くやっていくしかないということ、そして結局は技術力だけでは組織や業務を変えれなくて、自分たちにとっての問題とは何か、本来やるべきことは何かを明確にして取り組むこと、それを関係者と意識合わせすることが重要なんだなというのを改めて感じた。Codeについてのお話だった。会社としてはOpenStackやk8sを得意としているとのこと。コードの管理自体はgitで行い、変更レビューをGerritで、このレビューが通ったものをJenkinsで自動的にデプロイしているとのこと。ReviewJenkins監視にはPrometheusを使っているが、大量のプラグインや細かい設定ファイルを扱っていると監視項目の定義忘れや設定漏れ、エージェントへのプラグインの配布漏れが出てきてしまうので、コード化しているインフラ設定群から何の設定が入っているかを読み解くSaltのコードからPrometheus設定ファイルを自動生成しているとのこと。database最初から良かったわけではなく、ここに至るまでにいろいろなことをやってきたとのことだった。Saltは使ったことがないが、対象サーバの台数が増えてくるとAnsibleでは手に余りそう、というのはよく聞くので(実際にそんな環境に遭遇したことはないが)、Saltのほうがよさそう(適当)。ツールは置いておいても、物理サーバ1万台規模でこの仕組みを作ってうまく運用を回されているところは素晴らしかった。コメントをキャンセルメールアドレスが公開されることはありません。