今日は July Tech Festa 2017 ( #JTF2017 ) で発表をしてきたので，さっそく参加レポートをまとめた．運営の皆さま，お疲れさまでした！

発表資料

感想 / 補足など

今回は「急成長するサービスを支える DevOps 戦略と組織変革へのアプローチ」というタイトルで発表をした．タイトルが良かったのかもしれないけど，会場はほぼ満席で嬉しかった（空席が目立つ会場もチラホラあったため）．

発表内容としては大きく3点で，DevOps の話と組織変革の話をバランス良く混ぜることを意識した．特に「組織変革」の部分が重要で，組織課題が残っている状態でどんなに頑張ってもサービスは伸びないと思っている．「DevOps は文化である」ことはよく知られているのに，文化として根付かせるために変化を実践できている人は案外少ないのでは？

急成長を支える ( ≒ 守る ) ための DevOps 戦略
急成長を支える ( ≒ 攻める ) ための DevOps 戦略
DevOps 戦略に必須だった組織変革へのアプローチ

また，今回は発表が45分間と長く，参加者とシンクロしながら発表したいなと思っていたため，最初にアイスブレイクとして「ノンバーバルなコミュニケーション」の例として「うなずく練習」をしてもらったりもした．ミーティングの場でも重要なスキルなので，是非意識してもらえると良いのでは！

モニタリング + AWS Well-Architected Framework の話は，以下に記事を公開している．

developers.cyberagent.co.jp

「Aurora 事例祭り」で話した Aurora 移行の詳細は，以下の記事を公開している．

kakakakakku.hatenablog.com

経営層を巻き込んだ話のインタビュー記事も公開している．

developers.cyberagent.co.jp

コミュニケーションに悩んでいる人には以下の記事が参考になるはず．

kakakakakku.hatenablog.com

写真

f:id:kakku22:20170827140819j:plain

A00 : 「ITエンジニアリングの本質」を考える / @enakai00

How Google Works
Jupiter Network 紹介
- Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network – Google AI
- 特徴の1個 : Clos トポロジー
- 第5世代 Jupiter Network
Google では Software Engineer がネットワーク管理の仕組みも考える

ネットワークの話は難しい部分も多かったが，直面する課題に対して考え続けるという思想こそが，エンジニアリングの本質なんだろうなと感じることができ，素晴らしかった．特に資料の最後にある「技術的制約に対する洞察力」があるからこそ，現在の常識を壊すことができているんだと思う．

「ITエンジニアリングの本質」を考える from Etsuji Nakai

www.slideshare.net

B10 : Web サービスの信頼性を守るための取り組み / @rrreeeyyy

SRE : サイトの信頼性の全てに責任範囲を持つ
- Software Engineering
  - 自動化スクリプト / ツール実装 / プロダクションコードも直す
- Systems Engineering
  - 1回の作業で永続的な改善を生む作業
  - アーキテクチャ設計
- Toil
  - 繰り返し行われる手動オペレーション
  - トイルを無くすことが重要
- Overhead
  - 管理的な作業
  - 採用/ 評価 / トレーニング
プロジェクトごとに，1人 SRE がアサインされて，設計相談やレビューをする
アプリケーションの負荷テストを実施する
- そもそも，エンジニアが負荷テストを実施している時点で，Toil なのでは？
ロードバランサの改善
- ソフトウェアを自作するのも SRE の仕事
- GitHub - ryotarai/simproxy: Simple HTTP balancer (reverse proxy)

日本語訳の SRE 本は買ってあるけど，まだちゃんと読めていなかったため，理論的な部分と実践的な部分の話が聞けて，個人的には1番面白かった．エラーバジェットも実践しているという点も興味深かった．また，定義上は Overhead にあたり新卒研修も，改めて理解を整理できるだろうし，担当する SRE 側にも大きなメリットがあるだろうなと感じた．

C20 : 若手エンジニアの私が MBA（経営学修士）を取りに行った話 / @nari_ex

上司の薦めで，経営大学院に入学することになった
組織行動 (OB) と人的資源管理 (HRM)
理論と実践は違う − フィードバックをもらったり，ストレングスファインダーを試して，自分を知る工夫をした

自己過信によって失敗が続き，自分を見つめ直す中で，マネジメントに興味が出て，上司の薦めで経営大学院に入学したという話だった．個人的には，話を聞いていて全体的に甘いなという印象を受けた．マネジメントに限った話ではないけど，理論武装しているだけではダメで，実践してこそ価値があると思っている．そもそもメンバーからの信頼が無ければマネジメントなんてできないため，まずはメンバーから信頼されるためにどうしたら良いか？を考えてみるのが良いのではないかなと感じた．あと結局のところ，ビジネスの成功や，メンバーの成長など，目に見える成果が出ていなければ，マネジメントは成功したとは言えない点も重要だと思う．MBA は非常に興味あるなー！

A40 : Kubernetes でクラスタリングして解決したことと新たに出てきた課題 / @koudaiii

新規サービスの立ち上げを早くするために Kubernetes を導入した
rails c を実行するコンテナ，rake db:migrate を実行するコンテナなどもある
80個以上もあったチェック項目が，簡単になった
Kubernetes によって，スケールも容易になった

僕のところだと ECS を使っているため，Kubernetes は全然詳しくないが，大規模な Kubernetes 導入事例として非常に面白かった．特にサービス数が 9 → 60 に増えているという伸びが，まさに Kubernetes 導入が成功だったことを示していると思う．Kubernetes のマスターも3台構成にして，SPOF を回避しているとのことだった．