昨年から開催されている、年に一回の祭典「Jenkins Day Japan 2018」。
今年も非常に面白かったです。
こちら。
昨年との違い
昨年の記事はこちら。
大きな違いは、昨年は「SREのようなものを作っていく必要がある」という川口さんの講演があり、今年はその実例を聞くことができた。確実に少しずつ進歩している。…海外は。
しかも、海外の2事例は、面白くも両極端のようにも見える。
中央集権型と地方分権型。
しかし、いずれもスキルのある人を事業規模に合わせて選択し相応の報酬、権限を与えて運用しているということ。実は両極端ではなく、同じ施策を部分最適か全体最適か、という目的に合わせて選択しているだけ。
非常に興味深かった。
来年に期待することは、日本でのSRE事例が発表されること。川口さんの発表の中にあるように、事例発表をしていくことは悪ではない。社内にとどめるのではなく、成功も失敗も共有して、フィードバックループをまわしていけばいい。
社外発表申請が「本当に」重い会社が多い。
やることをやっているなら、もっとその事例を出して、よい策を享受するようにしていけばいいのにと思う。
セッション紹介
以下、印象深かった二つの講演をご紹介。
大企業におけるDevSecOpsの変革
Moied Wahid 氏 Experian社 （元：PayPal社）
やりたいことはそれぞれで違う。
目先の、小手先のことをするのではなく、大局をみて、大きな絵を描いてやることが大事。北極星のようなものを伝えること。決めたビジョンをみんなに伝え、納得してもらうことが大事。
仲間を見つけていくことが大事。
ビルドするだけで24時間かかっていた。そこがボトルネックだった。
達成されたとき、マイルストンが達成されたとき、お祝いすることが大事。
それは、外から見えるようにするということでもある。アピール力。
見えないものを見えるようにすることが大事。
定量的に計測することで、カイゼンが進む。
そのままとどまるのではなく、プロジェクトサイズを大きくしていくことも大事。
自動化するには時間がかかるが、そこから先はそのうまみを享受できる。
そういう視点をしっかり持って計画すること。
サービスを開始するにあたり、検討したこと。
JS,C,C++,C#のチームがいるとする。
最初からある程度の自動化できるしくみを準備した。
どんな環境が自分たちの組織にはあるのかを把握し、共通化できるところを見つけた。
５７０万件のテスト・・・毎日生み出されている。
巨大な環境をしたから支えていたのがJenkins。
再現可能性。それを達成するには、パッケージングする必要がある。
巨大なスケールでの運用をしていると、あるべきものとのずれ、ドリフトが発生して、物事を難しくしてしまう。
モニタリングも必須。
ドリフト部分を発見できる仕組み。
計測するとノイズも入るので、真の値を見極める仕組みも必要。
インフラがコードとして整備されている、これは大事なことである。
作られたバイナリをデプロイすること。
ソースコードの責任者を把握しておく。
ソースコードのトレーサビリティ・・意図との追跡可能性が重要。
ブランチ戦略はあまり気にしていない。Git-flowなどで簡単な仕組みで回ればそれでいいと思っている。
１２０億のサービスエンドポイントへのアクセスを生む、そのくらいの大規模なシステムで動かしている。
これだけ大きいと、サイロ化されたテスト環境は現実的ではない。共通化された環境が必要である。
運用可能性。実行状況を把握できるメトリクスをとったり、ログ戦略をたてたり、起こったことを後からちゃんと追跡できる仕組みを重要視して構築した。
ソフトウエア生産性に重要視して真摯に投資してきた会社というのは、優秀な開発者を引き寄せている。
開発者に権限を与えてあげる。
開発者はQAにコードを渡しておしまいではない。本番環境にテストして失敗したものがいかないようにする仕組みを用意してあげる。
自己修復してくれる有機的なSWを作る必要がある。
うまくいかなかったインタラクションのデータを取得して、なぜうまくいかなかったのかをスピード感をもって解決できることも価値となる。
これを続けていき、ソフトウエア技術者の価値を高めていく。
ソフトウエア開発者への投資をしていくことを強く言い続けていきたい。
会社の経営層、開発者、それぞれの立場の人向けのダッシュボードが必要。開発プロセスをいじった時に、どういう影響を及ぼすのかという影響範囲・・原因と結果を結びつけて解決することができる。それぞれの立場からの究明。
問題を発見するためのサイクルタイムを短くする。その仕組みを作ることに投資を惜しまない。
開発チームと運用チームに分かれていたが、今は一緒。投げ合うのではなく、googleなどで提唱されているDevOPS-SREを構築した。
実行時のソフトウエアの性能などに責任を持っている人たちをSREという。
新しいSWをつくるのに、ダウンタイムなしに作業に移れる仕組みを構築している。
ダウンタイム＝お客様と話したり、「止まってしまう」時間のこと。
みんなのソフトウエア開発を支える組織。このチームにこそ、他よりもスキル・能力のある方たちを配置する。
自動化なしにはもう成り立たない環境。そこを「あたりまえ」に支えるチームにこそ光を。
IaSの考えをもって仕組みを構築している。
社内のことだけに視野狭窄になるのではなく、産業全体にアンテナを張り続け、その成果を自分のプロジェクトや環境に反映し続けることも大事。
当然、産業へも。共益。
シェアドサービスの人たちがもっと組織に理解され、その功績をアピールして立ち位置を揺るぎのないものにする努力をする人が必要。
DevOpsを前進させるCloudBeesの取り組み
川口 耕介 氏 CloudBees, Inc. Chief Technology Officer
スケールアウト。人のスケールアウト、組織のスケールアウト、インフラ。
できる人は社内コンサルみたいになってしまって、ぜんぜん技術が組織にスケールアウトしない。どこに必要で、どこに課題があって・・・というサイクルを回すには、データの力が必要。
全体をみてクローズアップしていって課題を見つける必要がある。
ガバナンス 企業のプロセスをどう分解して守り、エンジニアにとって蜘蛛の巣みたいにならないで済むのか？
いいプロセスをどう適用していくのか、開発者に価値を届けられるのか。
目に見えない「人のアクティビティ」を可視化しなければいけない。
現場の人たちの仕事の負担を軽くしてあげたい。注力させてあげたい。
中央の人たちが開発する人たちにペコペコしないで済むようにい押し疎通してできるようにしたい。
パイプラインを中央の人がコントロールした方がうまくいくのはわかっている。
⇒開発者が今までやっていたことを取り上げてしまう。そうでなくて、どうぞ、そこは知らなくてもいいんですよね、別なところに注力してください、というように持っていきたい。
結果の利益だけを享受するだけでうまくいくようなことを考えている。
プラクティスとして取り込んでいる。自動化にあったプロセス、文化を作っていく
DevOPSはエンジニアリングのためのエンジニアリング。
２段階のテコが働く。だからそのつなぎの部分は本当に大事。
全体にかかわる話になるから経営層の理解も必要、納得も必要。上からも下でも納得をしていないといけない。
事例発表をしていこう。みなさん！積極的にです。
会社の名前を出して発表できないのは、何がいけないのかな？
国内だけで済む時代ではない。我々はそのままでいいの？
自分たちの組織の中でどう変化させていかなければいけないのか、を共有してほしい。
チェンジエージェント。
あらゆる人がSW産業にかかわっていく。農業など。
トラクターがデータを取得して、解析して、適切なところに適切な処理をできるようにする、とか。
自分のクリエイティビティを発揮して自分の技術で解決したい。
クリエイティビティをしっかり把握する必要がある。これは営業？
その技術でどのくらい利益が得られるのか？などの予測できるようにならなければいけない。可視化。
なるべく早く得られなければいけない。
一見相反する課題を解決することができる。
データを理解することでよりよいアクティビティを起こせるようにする。
何が産業にとって一番大事なのか？
広い視野で、俯瞰してみていきましょう！
おわり。
