aretan.jp

Scrum@Scale入門 アトラクタ 原田¶

About the institute 権力の源泉

農耕時代は土地持ってる人が強い
産業時代になると資本持ってる人が強い
情報時代は手を動かして働くのは弱くなった
そして、情報や知的労働力が強い
Developerは知的労働力
C&C研究所が作っている

本：パワートゥザエッジ （10年前）
米軍の組織をどう組織を作るのか
＊組織末端への意思決定権限委任
＊自己同期化
＊状況認知の共有

米海軍で屈指の潜水艦艦長「最強組織の作り方」
Turn the Ship Around!
今までの軍隊だと、間違ってても従う。

The Age of Agile 世界銀行で働いていた
ビジネスサイドの人が書いた本
うまくいってる組織の特徴
→顧客、小さなチームたち、ネットワーク

チームの人数
Agileチーム9人：だいぶつらい
5人から7人が最適だなあ

何をスケールするか？
家をコピペしてみた、ビルもコピペしてみた。
トルコで城を大量に作った
同じものをコピーして横に作ろうとみんな考えるけど
コピペ住宅、コピペチームなんて作れない。
ただ膨張させただけではないのか？

チリの貧困者用住宅：Alejandro Aravenaが作った
空いたスペースは自分で勝手に作る
どうやったらそれ作れるの？というコミュニケーション

プロダクトオーナーのWhatとWhyを作るチーム
スクラムマスターの開発チームの２チームで構成する

幾何学数滴にスケールしたいならスケールフリーにする
生物では、スケールフリーアーキテクチャはよく見られる
階層構造とフルメッシュの間ぐらいの形をしている

SAAB Technologiesは2000人を1.25時間で同期
７：３０ Daily
７：４５ Scaled Daily SoS
８：００ SoSoS
・・・ Executive Action Team
かならず６ヶ月に１回新しい戦闘機を作る

EATに必要な人とは？
EATには承認なしに会社のルールを変更できる人
財務権限をもつ人
スクラムのチャンピオン
変化を促すリーダー
人事・法務

スクラムマスター側のスケールは。。。
メタスクラム
プロダクト＞イニシアティブ＞フィーチャー＞エピック
ビジョン＞コンポーネント＞フィーチャー＞エピック

大企業は：そんないい加減なやり方でいいのか
小企業は：そんな大変な方法でやるのか

Scrum@Scaleで言ってるのは、チームを壊さないで。
チームをそのままで、別の所にそげ変える。

3M-HISでのScrum@Scale
電話対応とかスクラムできないところもある

アジャイルのやり方をやったことのない、
マネージャーにタイムボックスと透明性を経験し
練習する機会を提供できる。

エンジニア経験を持ったマネージャーに、
エンジニアリングの知見を活用したマネジメントできる

必要最小限の権威主義を提供する。
チームの邪魔をしない、チームが早く動けるようにする

Cloud Native Docker Kubernetes サイバーエージェント 青山¶

Kubernetes完全ガイド、Japan Container Days Keynote
Instagramable Kubernetes
CloudNativeとは何か？
CloudNativeComputingFoundation
疎結合なシステム、復元力がある、管理しやすい、可観測である、
堅牢な自動化により頻繁かつ期待通りに最小限の労力で大きな変更が可能

CNCFのソフトウェアはほとんどCloudNativeEcosysytem、Kubernetes前提
クラウドネイティブをしようとするとマイクロサービスやサービスメッシュに
マイクロサービスは機能ごとにシステムを作る
TwitterやNetflixでは500以上のマイクロサービスが存在している。
これって、管理できるの？
それを解決するために、サービスメッシュがある。
TrafficShifftingもできる（Canary Releaseとか）
Circuit Break,Fault Injection、Rate Limit、mTLSなどもできる
開発者はアプリケーションのロジックにだけ集中することができる

Container（System Containerは親がInit、Application Containerは親がApp）
Docker Containerを起動すると、あらたに書込み可能なレイヤを作る。
そして、元々のレイヤは読み込みだけのレイヤ
・・・によって、疎結合で復元力があり管理しやすくなる。

Container Orchestration Engineは
複数のDockerホストの管理を可能にするなど・・・
これは、クラウドネイティブの定義を満たすために存在している・・・
Kubernetesは複数のDockerホストを管理するのではなく・・・
コンテナホストの管理を行う、コンテナランタイム環境。
CRI：Docker、Cri-o、Containerd
OCI：Runc、Gvisor、Firecracker
Dockerを勉強するより、K8sの勉強をしたらおっけ。

K8Sがもたらすもの３つ
①Declarative Code and APIs
KubernetesはぜんぶYamlですべてを管理する。
②Self-Healing
障害の影響をとどめる。別のNodeで起動する
③Rolling Update（Automation)
Developerはマニフェストを変更するだけですむ

拡張性の話
YamlでK8sに登録するとコンテナ軌道したりしてくれる
でも、単純にマニフェストの内容を実行しているわけではない
Control Loop：観測、理想と比較、差分の処理を実行
AWSやGCPやAzureなどをコントロールすることも可能になる
Queueクラスタを展開するとか
プリセットしたものを対象にできる
これがCustom Resource Definition
KubebuilderやOperator Frameworkで簡単に作れる
データセンターをまるまるK8sで管理するとかもしている

Knativeサーバレスプラットフォームを作る
Kubeflow、Operator Frameworkとか

CI/CDはどうするの？GitOpsがおすすめ
Stagingクラスタに登録、そしてProductionクラスタに登録

インターネットバンキングMnzoはK8sとLinkerdを使った
Linuxはずっと存在しつづけたように、K8sも存在しつづけるんじゃないか

VPoEとしての組織変革への挑戦 ビデオマーケット 里山¶

YahooAndroid黒帯、クリエイターエバンジェリスト
成果を出しやすい組織を作っていく仕事
今までやってきたこと
今やっていること
今やりづらいこと
３年後どうしたいか
今できる１歩
を１：１で話し合ってきた。
悪いところは大量にあるものの、メンバーの意識は高かった
足りないのはスキルではなく、ボトムアップの仕組みだった
だからビジョン・ミッションの設定をすることにした
ビジョン：プロダクトの未来は自分たちで決める
ミッション：感に頼らず根拠を元に開発する
コアバリューの作成
プロダクトがユーザーに対して責任をもつ体験価値
ユーザが環境を気にせず、安心して、簡単に、動画を楽しめる
本当はユーザーの調査を元につくるが、メンバーで作った
攻めチームと守りチーム、守りは外注メイン
枯れた技術でエンジニアのモチベ低下などもあった
根本から見直すアーキテクチャの必要性
ピンチをチャンスにする技術選定：Flutter
GCPでMicroservicesとKotlinに変えた
認知と採用戦略：感度の高い人を採用しやすいように
団結の海賊旗：会社の文化やレガシーを変えるためにすべてを疑う
チームの団結の象徴、セクショナリズムに負けない意思の表明
コミュニケーション活性化で、関係が悪化する人も・・・
大手もベンチャーもエンジニアのスキルに対する差は大きな問題じゃない

エンジニア文化で大事なこと
経験できる環境、成果を出しやすい、主体性を信じる、効率化を称賛する
現場の不満や不安を解決する形になっているか
未来を信じさせられてあげれるか
稼働に対価が得られるか

エンジニアリングマネージャの本質：
心理的安全性を確保する、不確実性と戦う勇気、成長と評価につなげる
個人プレーにならないように、メンバーの成果を重視する

エンタープライズ巨大アプリをマイクロサービス化 ドリーム・アーツ¶

ドリーム・アーツ、BtoBで大企業の協創をする会社
グループウェアやチャットサービスなど・・・
エンタープライズがお客様で、高品質なサービスを提供する。
本部と店舗を連絡するサービス Shopらん 2008年にローンチ
VelocityテンプレートエンジンやAngularやStrutsのモノリシックアーキ
キャッシュ温めるために起動に30分もかかる
Mod_Proxy_AjpでLBしてTomcatいっぱい、ChefやDockerを使ってる
サービス継続するためにぐちゃぐちゃの現状から変えたい
これを同じアーキテクチャでやっても、モチベーションが持たない
去年ぐらいからKaaSがすげー使えるようになってきたぞ！
既存のシステムがAzureのDBを使ってるから、AKSを使うことにした
たとえば・・・SessionServiceを外部に・・・
If microserviceAnabled() して、従来の実装も使えるようにした
そして、サービスはSpringBootとSwaggerで作ることにした
FROM openjdk:8-jre-alpine
EXPOSE 443
ADD service.jar
ADD p12
ENTRYPOINT spring.config.location="yaml"
そしてACR(Azure Container Registry)にプッシュ
Github Maven Docker ACRというCIプロセス
今後のタスク：
＊Jacocoでカバレッジレポートが出せてない
＊サービスを組み合わせてのE2Eができてない
Yamlをいっぱい書かなきゃいけない、そんでKubectl applyする
VolumeMount:mountpath:/etc/config
Kustomizeを使ってYamlを管理するようにした。
これはKubectrlに取り込まれていく予定らしい。
/session/base/deployment.yml
/session/overlays/production/config/application.yaml
のように作っておけば、合成していい感じに作ってくれる。
kustomize build | kubectrl apply -f のようにする。
ログはホストの
/var/lib/docker/containers/... Read only Volume
にぶちこまれていく
FluentDでElasticsearchに送信するようにした。
GithubのNebosuke/memoにFluentdを使ったときのメモ

パフォーマンスの話、今までだとナノ秒のオーダーなのに
ミリ秒のオーダーになる。4倍ぐらいの差が出た。
でかく切り出していかないと、もったいないぞ。
サーバーサイドも非同期・並列プログラミングできるか
あとResilience4jとかでコントロールできるんじゃないか
ほんとはViewとControllerで分けるんだろうなあ。
SOAの再発見、テクノロジーが揃ってきたという背景がある

共通サービスはでかいオーバーヘッドがあろうと切り出す必要がある
だから、先に個々に挑戦した。のちのちに、
本当の形であるViewから呼べるようにしたいと思っている。
分散トレーシングをもっとしたい。
モニタリングももっとしたい。
サーキットブレイカー

いかにして熱をあつめ伝導するか エムオーテックス こにし¶

Jaws-UG Osakaのメンバー
セッションのテク：早口で話して、伝えたいところをゆっくり話す。
サッカースタジアムでJaws festaをやった
芝生に入ると、すごく高いから、芝生の外でやった。
実際にはスタジアムの売店のスペースでセッションを開いた。
エンジニアとして必要なこととは：
インプット最大、アウトプット最大、アピールして認められる
つながりを大切にする、夢を描く、そのために勉強する。
インプット・アウトプットのサイクルを回す事が重要

カンファレンス＋パッション＝城¶

城でテックカンファレンスを開いた、門でトークをする
地酒を購入して懇親会は天守閣貸し切り
楽しんでくれそうな人に話しかけて10人を確保
イベントをやる理由は、趣味だから。
学びの方を優先しがちだが、人と人のつながりを重視したい
人のことを知った上でのプルリクは障壁が低い
有名なPerlモンガーと繋がれてイベントを作ることができた
リアルなリレーションがあれば、打算抜きで応援できる
ロールのある人間は社交的になる
今はなんでもインスタばえを狙っている
何度もカンファレンスやってると、定型化して飽きてくる

LC4R1、Janog41、42で話した¶

ColaboratoryでJupyternotebookが使える
Ansibleとかも普通に撃ったりできる
!/cat/issueでOSバージョン取れたりする