Developers Summit 2019 Day2

ソフトウェア開発の今ここに適応するために新井さん¶

新たな出会い
組織の変え方
組織のあり方

どうにかしたいもの
ビジョナリーの価値観
文化体質を変えたい

アーキテクチャは組織に従う
組織はアーキテクチャに従う
指示待ち、モチベーション、忖度
改善ジャーニーカオスマップを作った

フレームワーク主導はNG
悩みを解決するために使う
みんな貢献意欲をもっている
トリプルループ学習をする

チェンジエージェントの特徴
公園で的確な質問する人とか
Taker Matcher Giver
他者志向のGiverになる必要がある

前のめりでタスクを取ってくる人との出会い
貢献することで影響になる
瞬間的なコラボレーションはあるが
最高のチームは少ない
職場に安全であたたかい空間をつくる必要がある
人を助けるとはどういうことか
公平な関係を築き、どんな支援が必要か明らかにする

血があつい鉄道ならば走りぬけてゆく鉄道は心臓を
新たな旅を・・・

我々に越境できない境界はない市谷¶

現場で越境しようとしている人のための本
あなたは何者なのかという問いの本である
帰ってきたボールがボーリング玉ぐらいの人もいた
組織を超えた学びの場をつくる
スペースをつくり、スペースをあける
かつて、コミュニティは夜戦病院だった
癒しを得て戻るべき場所に戻る
DevLoveの復活をさせるためにガソリンが必要だった
人間を一人ずつのリソースとして数える時代は終わる。
一人の人間が何に時間を使うかポートフォリオの時代。
自立しながら、ともに働くチームが得られる場を作る
組織があるからチームができるわけではない
共通する信念があるから、チームはできる。

役割・交流の場・ルール・共通の
むきなおり、何者でもない自分が何者かになれる可能性
我々の世界の構造、社会組織事業プロダクトチームを超える
この構造を遡ろうと考えている限りもうこれ以上はいけないな
自分たちの場所を作るのは自分たちだ
共にできるwhyがあることが重要である
取引から共創の世界に・・・
コミュニティは2回開催すると死ぬ
越境したら、とても手段がとても増えてしまう。
だから手段に恋をしない。目的に忠誠を誓え。
あなたはどんな作品に自分の名前を残すのか？
エンドロールに自分の名前を乗せるならどういう作品か？

メンバーの成長とチャレンジのために Yahoo山本¶

8年、コンピュータに向き合ってたのが、
2012年からSMとして人と向き合う仕事に
まず伝えたいこと、マネジメントって楽しい！
人たちをいきいきとさせて高度な成果をあげる
昨日の漆原さんのセッションが面白かった。
パフォーマンスの方程式 Robbins2001
パフォーマンス＝本来持つ生産性＋プロセスゲイン＋プロセスロス
適材適所の役割分担、コミュニケーションコスト
評価の本質は、期待値と現状認識を合わせること
成長やキャリアを支援する行為であり役割分担である
今までできなかったことが、できるようになったら、成長を感じる
成長支援において大切なこと
学ばざるを得ない状態をつくる、成長に気づいてもらう。

Lychee Redmine フューチャーアーキテクト¶

スケジュール、工数リソース、レポート、カンバンなど
トラブルの時にやること
ほってくと部分最適がすすんでいって、
当時のゴールから大きく離れていってしまう。
何を作る？どうつくる？どうやって確かめる？
てっとりばやく、説明してもらう。そして判断根拠を問う。
トラブル予防の3原則
1整理整頓、小さなほころびを見過ごさない
2トラブル前提、起きることを前提にする
3過信しない、コミュニケーションをしっかり
梯子を外されないように、反故されないように
整理整頓、整理とは、いらないものを捨てること
持ち主を決める、ステータスを決める、期日を決める
節電責任者、のようにする。
整頓とは、秩序を保って配置すること
トラブル前提は、リスクマネージメントの話
＋マイルストーンを踏み絵にする
＋勝つための王道で勝負する
＋カウンターバランスを演出する
＋王様は優しい
追加の4原則・・・

AbemaTVの挑戦と苦悩 CA 山中¶

インターネットでリニア型放送をする
AbemaTV Developer Conferenceの抜粋版
なぜGCPを選んだのか
高機能のl7ロードバランサ
GKE・Kubernetes
ネットワーク帯域のコストが安い
ログ収集や集計サービスの充実
これらが選定理由
GCPは東京リージョンがなくて
日本と台湾間のネットワークの課題にあった
最初JavaでNode.jsでGoに変遷した
マイクロサービスアーキテクチャの採用
AbemaTVには80のサービスがある
各サービスはgrpcとProtocolbuffersで通信
GatewayPatternを使用している
半年でメジャーバージョンが上がるから、
1年でもうEOLになっていくというつらみがある
GKEはGCPを使う最大のアドバンテージ
スキーマの柔軟な変更が求められたのでMongodb
MongoDB cloud managerで管理している
Goのインメモリキャッシュをよく使っている
あとはセッションやロックなどのためにRedis
TerraformとPackerで構成管理している
クライアントとサーバーの通信はProtocolBuffers
今ではGCPで対応されたのでgrpcにしたい
メディア以外はLBに付帯するCloudcdnを使う
Server-Side Ad Insertionで広告を挿入している
VOD型はClient-Side Ad Insertionで挿入している
→シークできるから、クライアントで挿入することに
Google IMAのSDKでvastで通信を行う
CodeshipとDeploykunを使ってCI/CDを構築
Deploykunは社内で作ったチャットオプス用のもの
監視はBugsnagでスパイクやエラー監視をしている
Google Cloud MonitoringでGCPを監視
PagerDutyでオンコール体制の見直しをしたい
アプリのログはfluentdでStackDriver Loggingに。
アクセスログはCloudPubSubとBigQueryに変えた
Streaming Inserterの運用と管理がめんどい
なのでCloudDataflowとApacheAvroに置き換えたい
ApacheAvroはGCSからBigQueryがサポートしてるし
スキーマがファイルに含まれてるので管理不要
メトリクスはRedisやMongoDBはStackdriver
ほかのはPrometheusとGrafanaで可視化
現時点では、CPU使用率とかでしかスケールできないが
予測を使ってスケールしていけるようにしたい

安定の定義が必要、SLOが満たせば安定しているという共通認識
エラーバジェット＝１ーSLO
エラーバジェットの消費状況をモニタリングして、
エラーバジェットが無くなりそうなら抜本的な対策をする
→開発は新機能開発をやめて安定化に協力する
→SREが改修を行うこともある
重要なことは、協力して解決するということ
プロダクトマネージャーはこれは困ってしまう
稼働率何パーセントを目指すかと聞くと、みんな100％という
でも100％だったらずっとこれのために働く必要がある
だから、SLOをいい塩梅になるように調整していく
安定化に必要な開発ポリシー
＊設定ファイルによる追加機能のONOFF
＊ロールバックの自動化
＊カナリアリリースに対応した設計
Toilの削減・労力のかかる作業を減らす
Burnoutをいかに防止するのかが重要である
そのために、これらの対策をとっている。
Postmortem、障害対応が終わった瞬間に
みんなで一斉に発生要因、反省点、改善策を文書化
個人を非難する内容は絶対に書かない
個人のミスを誘発するシステムを設計したSREの責任
改善策の実施は、SREチームのプロジェクトとする

描いてシェアして伝えていこうサイダー高野¶

slコマンドを作った人が部長だった
私にとってインターネットはやさしい世界
プログラミングを覚えるのが楽しかった
大変だったけど今思うと生産性は高くなかった
あかちゃんはDevして完了せず24365のフェーズに
若い頃は生産性を度外視してやればいいけど・・・
キラキラした世界がどうしても目についてしまう
予算が少ないから、OSSに触れる機会が増えた
大変な時こそ足場を固めるという選択も悪くない
父が災害にあって・・・たってしまった。
1度の人生だから、後悔しないように生きたい。。。
待っていれば、制度は整ったかもしれない
ただ、わたしにはその時に必要だった
あと、もういちど、開発に戻りたかった
上にもいけない偉くもなれない、ならやりたいことやりたい
小4の夏、もっといっしょに過ごしたかった。
転職先は雲（クラウド）の上の会社だった
一次面接でカスタマーサポートを希望してたけど
開発部門に採用されることになった。
初プルリクに、まさかりが飛んでくる。
そんなルールどこにあるの？どこ見ればわかる？
わたし以外はどんどんマージリリースされる
とにかく、戦力にならない日が続く。。。
転職先で馴染むってほんとうに大変だと思った

Yoda: You muse unlearn what you have learned
dbから構造をひもとこうなど・・・得意なことから攻めた
こつこつとコンフルエンスに書き出していった。
質問しやすい人、dbちょっとわかる人として認識されるように
新しく入った人がすぐにパワーを発揮できるようにしたい
絵を描くことは緊急手段、お仕事の世界ではNgと思っていた
そこから、グラレコをするリミッターがはずれてしまった。
自分の見聞きしたことをできるだけうまく伝えれるように。

IstioとGKEで構築するクラウドネイティブアプリ福田¶

Why istioが登場した背景
What istioとは
How どのように動くのか
Where どこで動かすのか

Why ソフトウェアが世界を飲み込む
どんどんとデジタル化されていく
業務効率をよくするツールとしてのデジタルだったが
今や、アプリケーションは不可欠。だから
誰かに任せるわけではなく、積極的に関与しなければならない
スケーラビリティ、可用性の向上、そのための分散
でも、分散環境でアプリケーションを動かすのは難しい。
これを解決するためのものが、K8sであり、Istioである。
クラウドネイティブ
Biz Time to market、停止時間が最小限
Dev 任意のコードで開発できる、アプリケーションに集中できる
Ops 自動化、苦労が少ない、観測性の確保、宣言型API
クラウドネイティブは本当に自分たちに必要なのか？

What Istioとは？
サービスメッシュと呼ばれるソフトウェアレイヤ
サービス間通信を管理するためのプラットフォーム
「アプリケーションロジックをネットワーク機能から分離」
クライアントはリトライの処理とか、あきらめるとか、
呼ばれる側からすると、リミットするとか、必要になった。
Istioはこのネットワーク機能を担当してくれる
Istioがもたらす価値
＊トラフィックコントロール
＊可観測性
＊セキュリティ
＊どこでも使える
大体障害がおこるのは、なんらかの変更が行われた時である
だから、Canary Releaseをつかうばあいが多い
Istio以前だったら、LBで10%をCanaryに向けたりすると
10％のコンテナが必要だけど、Istioならいい感じにできる
User-agent: regex: iphone
とかで振り分けたりもできちゃう
ゴールデンシグナル：エラー率、トラフィック、レイテンシ
システムの状態を知るのに、どういう値を見ればいいのか
ある経路からならアクセス許可する・・・とかもできる

How どのように動くのか
サイドカーコンテナ、Ingressが埋め込まれ、
全部のサービスにプロキシが挿入される
Pilot discovery
Mixer
Citadel

Where どこで動かすのか
GKEなら、有効にするボタンを押すだけで組める。
StackdriverでSLOが設定できるようになっている。

Added by aretan 2019-02-15 ago

1200.png View (113 KB) 2019-08-24

Project

General

Profile

aretan.jp