カオナビのDevOps実践 ~ 運用自動化・テスト自動化の秘訣 ~
カオナビでは、自社システムの運用・保守を日々行っていく中で、定常業務を手動で対応してきました。
しかし、開発規模・運用規模の拡大に比例して作業量も増加し、手動での運用に限界を感じるようになっていました。
起きていた問題としては、主に
・「運用でカバー」する事による作業時間の圧迫
・自動テストの整備不足による手動テスト工数増加
・手作業によるヒューマンエラーリスク
です。
この問題の解決策を模索していく中で、DevOpsという単語をよく見るようになりました。
開発部門の中でも2020年頃からDevOpsへの関心が高まり、積極的に自動化・見える化・効率化に取り組むようになりました。
その中でも、特に注力したのが下記の3点です。
・業務自動化用サービスサイトの開発
・リリース自動化
・E2Eテスト開発
本セッションでは、上記対応を進めていく中で、発生した課題とそれに対する有効な取り組み、取り組んだ結果得られたものについてお話します。
Outline/Structure of the Sponsor Talk
- DevOps実践の背景
- サービス拡大に伴う安定した運用
- 社内サービスの開発・運用
- 手動作業から自動へできたもの
- 安定及び自動化をすすめたリリース作業
- シェルでのリリースをAWS CodePipelineに移行
- リリースのためのワークフロー整備
- 日々安定してリリースをするための施策
- E2Eテスト
- 戦略
- 発生した課題と対応
- バグ検出の傾向
Learning Outcome
各種自動化を進めるにあたって発生した課題・有効な取り組み・発見した傾向についての一例を認識することが出来ます。
Target Audience
DevOpsに興味を持ち始めた方。運用の自動化・テスト自動化の導入を検討している方。
schedule Submitted 1 year ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Yuki Nishimura - Airワークのサービス拡大に向けて課題を対応する中で見えたDevOpsの重要性と歩み
45 Mins
Talk
Beginner
昨年より「Airワーク 採用管理」のサービス拡大に伴いアーキテクトとしてシステム改善に関わりました。
Airワークはクラウド(AWS)で構築されたサービスで参画当初以下のような問題がありました。- DB負荷が不定期に高騰する
- アラート通知が月1000件以上発生
- AWS障害発生 → 再発対策の流れがうまく回ってない
- モニタリング基盤はあるものの何を見るべきかの更新がされていない
- デプロイ、切り戻しに時間がかかる
オンプレでの開発・運用経験を活かして、課題は一通り対応してシステムにはいっときの平穏が訪れました。
しかし、この平穏はそう長くは続かないという予想もしていました。
長期にわたる平穏のためには何が必要でしょうか。そんな時、対応していた時の気づきを思い出しました。「これらの問題、アプリの問題は開発チームで解決することができたはずだし、インフラチームは専任でいてインフラの問題も解決できたはずだ。解決できたはずの問題が未然に防げなかったのはなぜだろう」
ここで、クラウドのような変化の激しい基盤では特にDevOpsが重要になると気づき、アプローチを始めていきました。
このセッションではAirワークで実施した運用課題の改善事例とそこから得たシステム運用を安定化させるための実践トライ, 考え方についてお話ししようと思います。
-
keyboard_arrow_down
Shohei Ishikawa - BIMから建設DXへ -DX に向かうために、何を伝えるべきか
45 Mins
Talk
Beginner
2010年代、多くのウェブサービスが登場するなどOSSをベースに情報化社会が一気に進みました。一方、建設業界ではBIM(Building Information Model)と呼ばれる業界独自のデジタル化が行われてきました。しかし2020年代、建設業でもDXの波が訪れ「BIMから建設DXへ」と大きな変化が起きています。
本セッションでは、ソフトウェア企業がプラットフォームサービスへと変化するにあたりユーザーにこのDXへの潮流の意味をどのように伝えるべきかという問題への取り組みを、DXの資料を元に解説します。 -
keyboard_arrow_down
Ryusuke Kimura - レガシーなシステムをリプレースした後に起きた開発組織の変化について
45 Mins
Talk
Advanced
2020年2月私が入社した時、システムは現代のモダンなシステムとの剥離が出てきている狭間でした。
一方、会社はその後、すぐに上場をして、一気に組織の人数が増加しました。
システムも社会的責任を果たせるようにアップデートをしなくてはいけないのは自明で、「必要最低限のアップデートをする」という選択ではなく、「全てを作り直す」という選択をして、システムリプレースを行っています。
新しいシステムはモノリシックからマイクロサービス化に変更しましたが、私はマイクロサービス化に伴う組織的な変化、いわゆるコンウェイの法則を期待してマイクロサービス化の採用をおこないました。
本セッションでは、マイクロサービス化を行った後に起きた開発組織の変化について赤裸々にお話できたらと思っています。
-
keyboard_arrow_down
aki matsuno - 金融×Dev×Ops~5年間DevOpsを実践してきたチームの体験記~
20 Mins
Talk
Beginner
ミッションクリティカルな性質を持った顧客業務に対応するために、DevOpsを実践したシステム開発を金融領域で5年間行ってきました。
1秒の処理遅延が数億の損失に直結し得るシステムにおいてDevOpsを実践することで、多数の困難に直面することになりましたが、貴重な経験が多数得られ、DevOpsの意義も実感することができました。本セッションでは、実際にDevOpsを5年間実践しているチームの話や5年間実践してきて得られた経験をお話することで、金融領域においてDevOpsを実践することで得られる意義や、DevOpsを実践しているが故に発生した苦難をはじめとした日常業務のリアルをそのままお伝えします。
また、セッション後半では、DevOpsを継続的に実践していくにあたって個人的に重要だと感じた点についてもお話できればと思っています。 -
keyboard_arrow_down
Kouta Ozaki - 開発チームにオーナーシップを委譲するという手法
45 Mins
Talk
Intermediate
皆さんのチームはシステムデリバリのアジリティを最大化できていますか?
現代の開発ではコードの負債、複雑なコミュニケーションパス、ボトルネックの存在など、いろんな要素によって簡単にアジリティの低下を招いてしまいます。Chatworkでは現在、アジリティを最大化するために次世代開発基盤の開発を行なっており、組織とシステムを刷新しアジリティを最大化しようと取り組んでいます。
この中の取り組みの一つとして、開発者にシステム開発のオーナーシップを委譲することでコミュニケーションパスの最適化、責任の所在の明確化を行います。しかし、一口にオーナーシップを渡すといっても障壁はいろいろとあります。
特にセキュリティや監査、信頼性などの考慮は一定の規模に育ったChatworkでは必ず確保しなければなりません。
この課題を解決するためにChatworkではDevOpsの手法を使った開発者へのオーナーシップの委譲を推し進めていくという選択をしました。
本セッションではChatworkがなぜその選択をしたのか、どのように実現をしているのか、難しさや課題としてどういうものがあるのかという話をSREの視点からぶっちゃけトークをしていきます。(怒られたらマイルドな内容になります) -
keyboard_arrow_down
Yotaro Takahashi - 右手にThe DevOpsハンドブック、左手にクックブック
45 Mins
Talk
Intermediate
タイトルは「もしも食べ専エンジニアがThe DevOps ハンドブックを読んだら」など、ほか候補やより良いアイデアがありそうかなと思っていますのでぜひコメントでご意見ください!
私は妻と小学生の男の子二人、トイプードルの娘の5人暮らしなのですが、我が家の料理隊長である妻がアメリカに1年間行くことになりさぁ大変! 食べ専エンジニアの私が残された4人分の3食を毎日なんとかすることになりました!
食べ専から日々の料理を作ること、いやいや作ることと食べることだけではなく後片付けや調達、作ることとそれにまつわる運用、、、
あれ?これってDevOpsの原則が参考になるんじゃない?
というわけで手に取ったのが仕事で過去手に取った『The DevOps ハンドブック 理論・原則・実践のすべて』です。
このセッションでは、The DevOpsハンドブックに記載されている3つの道、すなわち①フローの原則、②フィードバックの原則、③継続的な学習と実験の原則、を通して、料理のワークフローの中でどのようにDevOpsの原則を実践してきたかの体験談をお伝えします。
-
keyboard_arrow_down
Hiroki Arai / Kenta Sasa - Value Stream Mapping ワークショップ Online
100 Mins
Workshop
Beginner
Value Stream Mapping を体験するワークショップです。 みんなで一緒にValue Stream Mappingを使ったプロセスの見える化・カイゼン案の検討を実際に体験してみましょう。
Value Stream Mapping = ソフトウェア開発工程の流れ(価値の流れ)を見える化するために作成するプロセス図です。アイデアが生まれてから顧客に対して価値が届くまでの全行程を見える化することによって、ムダな作業や非効率なフローをチーム内で共有することができるようになるため、カイゼンに役立てることができます。
4、5人でグループを作ってグループワークを行います。Value Stream Mapping が描けるようになるだけではなく、チームで作った時の効果も感じられると思います。
今回はOnlineということでDiscord+zoom+muralを使って実施しようと思っています。オンラインでワークショップってどんな感じなんだろう?と興味がある方も是非参加してみてくださーい!