デブサミ2019のCI/CDとかゲームQAとかの話 #devsumi

Developers Summit 2019、今年は2日目だけ行ってきました。テストとか自動化まわりのセッションの、気になったところだけのメモ。

全量、また、その他のセッションの資料はこちらのページに追々貼られるはず。

codezine.jp

【15-E-2】CI/CDを使い倒して数段上のソフトウェア開発をしよう！

speakerdeck.com

デブサミ2019【15-E-2】CI/CDを使い倒して数段上のソフトウェア開発をしよう！ #devsumiE - Togetter

CircleCIの金洋国さん。「なぜCI/CDへの関心がこれほど高まっているのか？」という問いかけから、CI/CDのWhat/Why/Why not/Beyndについて。

Why CI?
- 実行し忘れ
- 昔書いたテストが壊れて動かない
  - 「使われていない自動化は壊れていく」（出典：サイボウズを支えるCircleCI）
- テスト結果が環境依存
Why not CI?
- CI導入の障害
  - テストがない
    - テストがなくても、構文チェック、カバレジ*1、サイクロマティック複雑度、ドキュメント自動生成など、自動で継続的に実行できる（効果のある）タスクはある
    - 可視化する。バッジ、ダッシュボード、メールやチャットでの通知
    - マージブロック有効化
    - 少しずつテストを追加していく
  - メンテナンスがつらい → Jenkinsおじさん問題 → クラウド型がおすすめ
Beyond CI
- リリースまで自動化 → CD
What CD?
- CDのDは、Deliveryなのか、Deploymentなのか
  - Delivery: 常にリリース可能な状態を維持する。リリースには人間の意思が介在する
  - Deployment: 自動でリリースまで実行される
  - 広義のCD: ビジネス価値を継続的にデリバリーしていくこと。書籍『継続的デリバリー』はこの意味で使っている
- DeployとReleaseの違い
  - Deploy: 本番環境に配置する
  - Release: 配置したコードがトラフィックをさばく
Why CD?
- No CD, No feedback loop
Why not CD?
- アーキテクチャの問題
  - 疎結合にする、モダン化などの努力
- 組織の問題
  - 明確な答えは無い
  - 『エンジニアリング組織論への招待』参照
- ダメなら、早めにあきらめる
- 開発の初期に早めにCI/CDを入れる。「最初からクライマックスだぜ！」
Beyond CD
- カナリーリリース、ブルーグリーンデプロイ
- リリース間違ってもリトライできる → 心理的安全性
- CI/CD Makes programming fun!
- さらなる自動化に向かう？　CI/CD自体の設定、モニタリング、デプロイ環境構築など
- さらに「最初からクライマックス」に

参考

継続的デリバリー信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

作者: Jez Humble,David Farley,和智右桂,高木正弘
出版社/メーカー: KADOKAWA
発売日: 2017/07/31
メディア: 単行本
この商品を含むブログを見る

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

作者: 広木大地
出版社/メーカー: 技術評論社
発売日: 2018/02/22
メディア: 単行本（ソフトカバー）
この商品を含むブログ (3件) を見る

仮面ライダー電王 Blu-ray BOX 1

出版社/メーカー: TOEI COMPANY,LTD.(TOE)(D)
発売日: 2017/05/10
メディア: Blu-ray
この商品を含むブログ (3件) を見る

【15-C-4】ゲームQAを支える技術～前処理・後処理は大変だが役に立つ～

※スライドは追って公開されるそうです

デブサミ2019【15-C-4】ゲームQAを支える技術～前処理・後処理は大変だが役に立つ～ #devsumiC - Togetter

太田さんのセッション。AI技術を使ったゲームQAの話。

ゲームQAと狩野モデル
- 当たり前品質
- 一次元品質はゲームではあまりない
- 魅力品質
ゲーム内AI、ゲーム外AI（開発、運用支援、データ検証、性的コード解析、テスト）
AI for QA
- 当たり前品質
  - データ検証
    - コリジョンチェック、ソシャゲのキャラの性能評価など
  - ガチャの確率
    - 法規制もあり、受け入れテストとして実機で検証する必要がある
ガチャ確率確認ツール
- OCR(Google Vision API), C++
- 機械学習ではない
  - Google Vision APIのOCRは学習できない
  - ビルドパイプラインに組み込めない（3rdからバイナリとキャプチャ画像だけもらえる）
- 標準的OCRだと難しい
  - フォントを作りこんでいる
  - キャラ名、アイテム名が一般的でない単語
  - レイアウトや背景
- 偽陽性が多い、偽陰性はほとんどない
- OpenCVで前処理をがんばる
- 標準的フローに則る。検出できなかったりしてもオペレータがリカバリできるような流れ
- OCR 本来は95%くらいが損益分岐点
  - ツール的に、90%くらい出れば手動の1/3〜1/4くらいの時間でできる
  - 70%を下回るなら、全手動のほうが早い
- 行間を空けるとかの前処理で改善
排出率確認ツール
- まわして出てきた画像
- Airtestでキャプチャを取る作業は事前にやっておく
  - 10連ガチャでも、個々のカードに切り出しておく
  - 同キャラマージ表示（x3とか）とかがあると難易度が上がる
- 外部委託なので、機械学習は難しい
- 学習なしでできるか？ → 特徴量比較のみでやってみる → 分類数が多くなると無理
  - 誤分類はNG、過分類はある程度は許容できる
  - 1000overの微妙に違う「石」の画像
    - やっていると人間も学習するので見分けられるようになった
    - dot by dotの判定ならいける？ → ポストエフェクトがあるので無理
- k-meansベースの方式で改善
  - お手本分類の重心を取る
  - 一部手動と割り切る
  - レア度の高いものは標本が少なくて過分類になりがち
  - 手作業が1/10に。分類作業を含めても1/10なのでかなり効率化できた

参考

前処理大全[データ分析のためのSQL/R/Python実践テクニック]

作者: 本橋智光
出版社/メーカー: 技術評論社
発売日: 2018/04/13
メディア: 大型本
この商品を含むブログ (1件) を見る

【15-B-5】Site Reliability Engineering at Google

デブサミ2019【15-B-5】Site Reliability Engineering at Google #devsumiB - Togetter

Googleの中井さんによるSREの話。

Googleは当初から運用もSoftware Engineerで構成。目的はサービスを安定して提供し続けること
50%ルール。50%は開発にあてて、運用業務は残りで行なう
SREのバーンアウト防止
50%ルールをおびやかすシステムに対しては、開発チームに運用作業の返却、もしくは運用要員の提供を要求する権利がある
安定稼働を組み込むための技術支援もSREチームの業務に含まれる
SREの運用範囲は全システム/アプリでない。インフラ、ミドルウェア、重要度の高いアプリだけ見てる。
上記の範囲でも、すごく安定しているアプリケーションは見ない
SREチームの究極のゴールは、自分たちが運用するシステムをなくすこと
SLO (service level objective): 「安定」の共通認識
- Webリクエストに対し、n%のsuccess、m%は200ms以内にレスポンス、x%は1000ms以内、等
- モニタリングする
- エラーバジェット = 1.0 - SLO
  - 期間内(3moとか）のエラーの許容量
  - バジェットがなくなる可能性が生じたら抜本的な対策を講じる
    - 開発を巻き込んでやる。新規機能のリリースは止める
デザインレビューの提供
- 設計段階でSREチームを交えてデザインレビュー
- 運用まわりの設計が共通化・標準化できるので、SREチームとしても運用しやすいシステムになりwin-win
Toil（労力のかかる作業）の削減
- バーンアウト防止
  - Software Developerにつまらない作業をさせない → 50%ルール
- 運用作業・障害対応の自動化を促進
障害対応のプロセス
- 問題解決が最優先、他人に頼ることを本人のスキル不足とは認識しないことを徹底
ポストモーテム
- 重大問題の解決後に実施
- Google Docsでみんなで一斉に、要因、反省、改善策を書き出す
- 個人を避難する内容は絶対に書かない。個人のミスを誘発するシステムを設計したSREチームの責任という認識
- 社内の全エンジニアに内容を公開
  - 障害対応により得られた知見を共有
  - 障害対応の実地訓練にも活用（再現シナリオとして使う）
SREトレーニングコースがCourseraにある
- ポストモーテムの書き方とかもある

たぶんこれ

www.coursera.org

所感

運用は運用専門の部隊（だいたい外部委託）がいて、という状況からSREできる人だけ入れれば解決するわけではなさそう。（QA部門における）テスト自動化と似たような話が繰り返されそう。

参考

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

作者: 澤田武男,関根達夫,細川一茂,矢吹大輔,Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy,Sky株式会社玉川竜司
出版社/メーカー: オライリージャパン
発売日: 2017/08/12
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る