schedule Apr 25th 11:30 AM - 12:30 PM place Grand Ball Room people 22 Interested

DevOpsには技術的な側面だけでなく、開発や運用をはじめとするさまざまな部門を繋げる組織文化を構築するという重要な側面があります。 つまり単にDevOpsツールなるものを導入したりアジャイルなプロセスを導入すれば良いというわけではありません。

本セッションでは、主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を説明します。

 
4 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/Structure of the Keynote

Keynote speech.

Learning Outcome

N/A

Target Audience

Everyone

schedule Submitted 11 months ago

Public Feedback

comment Suggest improvements to the Speaker

  • Liked Shoji Shirotori
    keyboard_arrow_down

    Shoji Shirotori - データ分析基盤におけるOpsのためのDev with event driven + serverless

    20 Mins
    Case Study
    Advanced

    データ分析基盤の開発・運用において、サーバーレスやイベントドリブンなど新しいアーキテクチャを採用して、運用負荷の低減と機能開発への集中を行った事例をお話します。

    リクルートライフスタイルでは、じゃらん、ホットペッパーをはじめ、大小30以上のサービスを展開しています。
    データプラットフォームチームではすべてのサービスのデータが集まる分析基盤を有しており、サービス/ユーザーの分析のために無くてはならない存在となっています。そのためデータ分析基盤も、より高度な分析のための機能開発や安定的な運用が求められています。

    データ分析基盤のワークロードは安定運用、データ品質の確保、データ開発、ユーザビリティ向上など、一般的なアプリケーションとはかなり異なります。
    さらにデータ量は年々指数関数的に増加しており、運用にかかる負荷も増加しています。

    そこで運用工数の増加率を限りなく抑えるため、イベントドリブン+サーバーレスという手段を取りました。
    しかしこのアーキテクチャは、管理するサーバがなくなる代わりに従来のシステムとは異なる観点で運用を設計する必要がありました。

    サーバーレスなど新しいシステム、従来のシステムが入り交じるカオスな状況で、私たちのシステムのDevOpsのプラクティスはどう変わっていったのか、現場目線でお伝えします。

  • Liked Atsushi Fukui
    keyboard_arrow_down

    Atsushi Fukui - フルマネージドなAWSサービスで実現するコンテナへの継続的デリバリー

    45 Mins
    Demonstration
    Intermediate

    AWSのCodeシリーズを利用してサーバーの管理を不要にしたフルマネージドな環境で、DockerコンテナのフルマネージドなオーケストレーションであるAWS Fargateへの継続的デリバリーをどのように実現するかをデモを交えながら解説します。

  • Liked Kenji Kitaura
    keyboard_arrow_down

    Kenji Kitaura - Effective feedback from OPS case study in Rakuten email service

    45 Mins
    Case Study
    Intermediate

    私達楽天のEmailサービスチームは開発と運用を同じメンバーで行っています。
    DevOpsにおいて開発からリリースまでのプロセスは開発者から高い関心が寄せられており知見も十分に集まっている印象です。
    一方サービス運用に対して有効なプラクティスやツールの活用事例を耳にする機会はあまり多くなく私にとってはは試行錯誤が多い領域でした。
    どのようにすれば、リリース後にサービスを安定稼働させ稼働実績から有益ななフィードバックを得ることができるでしょうか?
    本セッションでは私達のチームが過去〜現在において直面している課題とその解決へ向けた取り組みやプラクティスを紹介します。

  • Liked Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi / SATO Naoki (Neo) / Takuma Ishibashi / Tsuyoshi Ushio - パネル : 昨年のシアトル DevOps 視察ツアーから今までを振り返る

    45 Mins
    Panel
    Advanced

    過去2回のDevOpsDays Tokyoは、2017年1月末のシアトル訪問から始まりました。
    Microsoftを訪問し、いくつかの多様性のある開発現場を見せていただき、英語での闊達な議論もしてきました。

    今年のキーノートの Chap Alex さんもそこで出会った一人です。
    彼はもともとテストの自動化の役職にいたわけではありません。
    スカンクワークスで数年、チームになって3年くらい、今は30人のチームになったといっていました。

    別のチームの人は、TFSというプロダクトを作っていましたが、
    「ほら社内でこんなに使われるようになったんだよ」
    と言っていました。計画経済のようにトップを説得して全体に使わせるなんてことはやっていませんでした。

    さらに、そのチームは部屋を工夫し、チーム全員が一部屋に集まり、それでいてほかのチームとは共有しない部屋を作っていました。徐々にほかのプロダクトに広がっていると言っていました。

    日本人エンジニアの河野通宗さんが言っていました。
    「上司もエンジニアなので意思決定が速いです」
    意思決定が速いと何がうれしいのですか?
    「クラウドは常にどこかが壊れている。なのですぐに検知して直さなきゃいけない」

    世の中がガラリと変わってしまう音が聞こえました。

    もう開発者もデザイナーもマネジメントも経営陣も関係なく、リアルタイムに動き続ける世界を相手にして動かないといけない。途中の誰かがわからないから通訳してくれといえば、そこでリアルタイムから弾き出される。

    テスト自動化だけ、チームビルディングだけ、上手なデリバリーだけ、得意ななにかをひたすら追いかけて、エンジニアのキャリアパスだけ考えて、残りはほかの人のせいにしておけばよい時代は終わってしまった。全体としていい仕組みを作った企業が生き残る。誰も安住できないグローバル競争をしたたかに生き残って時価総額を伸ばし続けるエンタープライズがシアトルに一つありました。競争している企業もいくつもあります。

    私たちの DevOpsDays Tokyo そこから始まりました。

    それから一年ちょっとがたちました。

    世の中の何が変わったのか、そして、心境はどう変わったのか、ここからどうなっていくのか。

    話し合ってみたいと思います。

  • Liked Takashi Takebayashi
    keyboard_arrow_down

    Takashi Takebayashi - To be or to do that is the question.

    45 Mins
    Experience Report
    Beginner

    上長に「お前は技術もマネジメントもビジネスも何も分からないクズ」と言われ、本当に自分が「技術もマネジメントもビジネスも何も分からないクズ」なのかどうかを確認しようと思い立った。

    確認する方法としてテスト駆動開発(TDD)でお馴染みの三角測量(その人にはたまたまそう見えたということが起こらないように2つ以上の値を使用してテストをする)で確認することに思い至り、ちょうどタイミングよく運転資金が枯渇し閉店を余儀なくされた馴染みの飲食店とパン屋があったので、そこに自己資金を運転資金として投入し、自分の技術と知識と能力を使って閉店を免れられるのかどうかを確認した結果を紹介する。

  • Liked 山崎泰宏
    keyboard_arrow_down

    山崎泰宏 - 運用(Ops)の自動化を目指すも何故か進まない、現場あるある打開策

    45 Mins
    Talk
    Intermediate

    運用の自動化は誰もが目指す理想郷である。しかし現場を見てみると、意外にもその思惑とは裏腹に、導入は進んでいない。特に複雑な運用ほど自動化すれば効果が高いのに、実施されていない。

    そこには、ひとえに運用におけるソフトウェア・エンジニアリングの考え方が不足しているのが理由に挙げられる。私達はソフトウェアを作り上げるように、運用を構成しなければならない。これはDevOpsに限らず、近年のSite Reliability Engineering (SRE)の骨子でも同様である。

    本セッションでは、運用の自動化を進めるに当たって考慮すべき事項と、その実現手段についてはMicrosoft Azureを用いた一般的なものから、物理ネットワーク運用への適用など特殊なものまで、実例をいくつか交えて解説をする。