サイボウズData Centerを支えるインフラQAの挑戦

Cybozu Tech Meetup #5 活動領域を広げるQA https://cybozu.connpass.com/event/183559/

でお話した資料です

Transcript

1. サイボウズ Data Center を⽀える
   インフラ QA の挑戦
   サイボウズ株式会社 運⽤本部 ⼭⽥ ⾼⼤
   1
   

   View Slide

2. ⾃⼰紹介
   n 2019年 1⽉ 中途⼊社
   l 現在 1年 8ヶ⽉⽬
   l 前職: B to B パッケージ製品の保守コンサルタント
   n 運⽤本部 SRE-QA チーム
   n その他経歴など
   l ⼤学まで離島で⽣まれ育ちました
   l 学⽣時代は認知・教育⼼理学やっていました
   2
   

   View Slide

3. SRE-QA?
   3
   

   View Slide

4. インフラ QA?
   4
   

   View Slide

5. 検索しても国内ではほぼヒットなし
   5
   

   View Slide

6. 検索しても国内ではほぼヒットなし
   6
   

   View Slide

7. 検索しても国内ではほぼヒットなし
   7
   検索結果上位に弊社関連ページ
   ※ 呼称 (検索ワード) が特殊・不適切という説はあります
   QA の定義にも議論はあるけどここでは社内通称 = SRE-QA を使います
   

   View Slide

8. ü ⾃社 Data Center (DC) を運営
   ü 開発から運⽤まで ⾃社で実施
   ü 150万 を超えるクラウドユーザー
   8
   特殊な環境だから必要な QA
   

   View Slide

9. 本発表の⽬的
   サイボウズ SRE-QA の取り組みの紹介を通して
   ü SRE-QA という職種を知ってもらう
   Ø 珍しい領域なので QA の世界の広がりの⼀助になれば
   ü SRE-QA における 開発スピード・品質を上げる取り組み の共有
   ü そしてサイボウズ SRE-QA に興味を持っていただければ
   9
   

   View Slide

10. サイボウズ SRE-QA とは
    10
    

    View Slide

11. n SRE と連携 する QA
    • SRE は 24/365 でサービス稼働を⽀える
    • 設計 ~ 開発完了までの 開発スパンが短い
    n DC 管理・運⽤プログラム の QA
    • CMDB, VM/LV 操作プログラム
    • MW セットアッププログラム
    n DC を⽀えるアーキテクチャの QA
    • ログ収集/解析基盤
    • Backup, Failover, Monitoring システム
    n 開発・検証環境の管理 (今回はあまり触れず)
    11
    

    View Slide

12. n 2020/8/19 現在 8名
    • 兼務 3名
    • Software Engineer in Test 1名
    n 求められる知識・スキル
    • Linux 操作 (基本的に試験は Command Line Interface)
    • Web アプリの基本, ストレージ, ネットワーク,
    セキュリティ, パフォーマンス,
    SLO (Service Level Objective) 観点, etc.
    • 様々な Middleware, サービス, ツールの知識
    12
    

    View Slide

13. View Slide

14. こんなに多くの範囲を
    ⼀⼈⼀⼈が全部カバー︖
    (これでもまだ⼀部)
    14
    

    View Slide

15. そういうわけではありません
    15
    

    View Slide

16. 16
    ü 開発スパンが 短い
    ü 扱うサービス・ツールが 広範
    ü Web アプリからストレージ・NWまで
    レイヤの⾼低も幅広い
    

    View Slide

17. 17
    こうした業務領域・環境下での
    品質を⾼める取り組み を紹介します
    

    View Slide

18. 取り組み 1:
    Buddy 制度
    18
    

    View Slide

19. Buddy 制度: SRE と QA のチーム
    ü 広範な領域をカバーするため,
    SRE 数名と QA 1, 2名で Buddy を組み
    専⾨領域 を作っている
    • その上で重要領域の QA をできる⼈が
    2名以上になるよう調整
    • Buddy 例:
    ログ基盤 Buddy, ストレージ Buddy,
    MySQL Buddy, NW Buddy, etc.
    19
    

    View Slide

20. Buddy 制度: SRE と QA のチーム
    ü 広範な領域をカバーするため,
    SRE 数名と QA 1, 2名で Buddy を組み
    専⾨領域 を作っている
    Ø 領域の 分担・専⾨化
    Ø SRE – QA 間の コミュニケーション促進
    20
    

    View Slide

21. 取り組み 2:
    ⼯程を問わない QA
    21
    

    View Slide

22. サイボウズ SRE の開発プロセスと⽂化
    In Design
    Design
    Review
    In
    Development
    Development
    Review
    Testing
    22
    n サイボウズ SRE の主な開発物と開発期間
    • 既存コードの改修 と 新規開発 がだいたい 半々
    • 期間は 数時間 ~ 数ヶ⽉, ⼤半は数⽇
    

    View Slide

23. サイボウズ SRE の開発プロセスと⽂化
    23
    SRE が主に担当
    SRE-QA が主に担当
    In Design
    Design
    Review
    In
    Development
    Development
    Review
    Testing
    

    View Slide

24. サイボウズ SRE の開発プロセスと⽂化
    24
    In Design
    Design
    Review
    In
    Development
    Development
    Review
    Testing
    ⼯程問わず
    コミュニケーション
    

    View Slide

25. サイボウズ SRE の開発プロセスと⽂化
    n 発表者の印象的な経験例
    Ø あるコマンドラインオプションの 必要性を本試験前に確認
    ü 機能削減 につながり保守性向上
    Ø Pull Request を⾒て 本試験前にユニットテスト追加依頼
    ü ユニットテストが追加され ⼿動試験範囲削減
    25
    

    View Slide

26. サイボウズ SRE の開発プロセスと⽂化
    n 発表者の印象的な経験例
    Ø あるコマンドラインオプションの 必要性を本試験前に確認
    ü 機能削減 につながり保守性向上
    Ø Pull Request を⾒て 本試験前にユニットテスト追加依頼
    ü ユニットテストが追加され ⼿動試験範囲削減
    Ø ⼯程を問わないやり取り が許容される ⽂化
    Ø Buddy プロジェクトでは 最初期 から関わることも
    26
    

    View Slide

27. 取り組み 3:
    Whole Team で品質保証
    27
    

    View Slide

28. SRE・SRE-QA 共に品質に責任
    28
    n 品質への姿勢
    ü SRE が 開発物の正常系試験をまず実施する
    • その後に QA 試験
    ü バグ発⽣時も SRE ←→ QA で
    他責にせず⽣産的な振り返り
    ü Buddy を組んでいると質問などしやすく
    知識の共有 が起きる
    

    View Slide

29. SRE・SRE-QA 共に品質に責任
    29
    n 品質への姿勢
    ü SRE が 開発物の正常系試験をまず実施する
    • その後に QA 試験
    ü バグ発⽣時も SRE ←→ QA で
    他責にせず⽣産的な振り返り
    ü Buddy を組んでいると質問などしやすく
    知識の共有 が起きる
    Ø Whole Team として品質に責任
    

    View Slide

30. 品質向上の取り組みまとめ
    開発スパンが短い・広範な知識が必要 な開発物に対し
    1. Buddy 制度
    ü 専⾨化と知識共有
    2. ⼯程を問わない QA
    ü Test になるまで待たずにコミュニケーション
    3. Whole Team で品質保証
    ü SRE, QA 共に⾃分事で品質保証に責任
    30
    

    View Slide

31. SRE-QA はサイボウズ DC の
    品質保証を担っている
    31
    

    View Slide

32. そして Neco/Maneki
    プロジェクト
    32
    

    View Slide

33. View Slide

34. View Slide

35. View Slide

36. 今後の展望・挑戦
    n Neco, Maneki
    ü Neco で Kubernetes ベースの DC にインフラを刷新中
    ü インフラ移⾏プロジェクトとして Maneki が進⾏中
    • すでにいくつかのサービス (機能) は Neco 基盤で 本稼働
    • 今年は Maneki チームと⼀緒に試験実施
    n 現⾏基盤の改善
    • 当然すぐに完全移⾏できるわけではない
    • ユーザーもどんどん増えてるのでこちらも 並⾏改善
    36
    

    View Slide

37. ※おまけ: その他の取り組み
    n 積極的に 試験⾃動化
    ü CLI なので相性が良い
    ü ShellScript がほとんど (⼀部 Python)
    n 開発/試験環境管理
    ü 全社の開発/試験効率化のため 開発 DC 管理の効率化ツール も作成
    n ⽉次定期メンテナンス QA
    ü Python, Selenium, kintone を組み合わせた
    メンテナンス確認⼀部⾃動化 など昨年実現
    37
    

    View Slide

38. SRE-QA に⼀緒に挑戦しませんか
    ü ⾃社 DC, クラウドサービスを⽀える インフラの品質保証
    ü ここ数年は DC インフラ基盤刷新 という 稀有 なタイミング
    • 国内で経験できるのは稀
    ü ⽇々勉強だがそれだけ 広範な経験/知識 も⾝につけられる
    ü 他チームの開発/品質保証効率化のための
    開発環境改善も担当 → SET 的経験も
    • カジュアル⾯談からでもぜひ (Twitter: @tyamada248 へ DM など)
    38
    

    View Slide

39. 画像引⽤元
    • https://www.oreilly.co.jp/books/images/picture_large978-4-87311-791-1.jpeg
    • https://design.ubuntu.com/brand/ubuntu-logo/
    • https://apache.org/logos/
    • https://www.mysql.com/common/logos/logo-mysql-170x115.png
    • https://www.elastic.co/jp/brand
    • https://www.graylog.org/
    • https://discuss.redash.io/
    • https://www.nginx.com/
    • https://staging.python.org/community/logos/
    • https://blog.golang.org/go-brand
    • https://www.docker.com/company/newsroom/media-resources
    • https://www.eclipse.org/jetty/powered/
    • https://www.datadoghq.com/ja/about/latest-news/resources/
    • https://www.freepik.com/vectors/work
    • https://github.com/kubernetes/kubernetes/blob/master/logo/logo.svg
    39
    

    View Slide