Project

General

Profile

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使用率とかでしかスケールできないが
予測を使ってスケールしていけるようにしたい

Google Site Reliability Engineering 中居

グーグルの中で、どんな風にSREをしているのか
別の企業でやっていこうと思うと合わないかもしれない
どういう歴史的背景があって生まれたのかとかを話したい
ソリューションアーキテクトは技術支援ならなんでもやっていい
ベンダーのプリセールスとは違って、本書いても何やってもいい
技術系のエンジニアならどんなPJのソースも見れる
ミッションステートメント:
世界中の情報を整理して、
世界中の人がアクセスして使えるようにする
世界中のDCが全部同じ標準で構築されている
ミドルウェアも徹底して標準化していっている
GoogleFileSystem Colossus Bigtable Spanner Chubby Maglev FlumeJava
などなど・・・これ以外のものは使っちゃいけない
マネージドサービスで便利なのがあると、使うよね。
SREはシステム運用のこと
グーグルも昔はフルスタックでやっていた
そして、運用チームもつくることになった
目的を「安定的にサービスを提供すること」とした
システムを運用するだけでなく、安定運用するための開発をあわせて行う
このチームの活動をSREと呼ぶようになった。
SREチームは50%を開発を含む安定化に関わる活動をする
残り50%でオンコールやPostmortemsやアドミ処理をする
SREは50%ルールを脅かすシステムは開発に返却か要員を提供する
SREの運用範囲:共通インフラミドル・重要度の高いアプリ
SREが関わる必要がないものはかかわらない
SREチームのゴールは運用するシステムを無くすこと

安定の定義が必要、SLOが満たせば安定しているという共通認識
エラーバジェット=1ー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