やらなイカ?

たぶん、iOS/Androidアプリの開発・テスト関係。

デブサミ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?
    • 実行し忘れ
    • 昔書いたテストが壊れて動かない
    • テスト結果が環境依存
  • 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自体の設定、モニタリング、デプロイ環境構築など
    • さらに「最初からクライマックス」に

参考

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

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

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

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

【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 APIOCRは学習できない
      • ビルドパイプラインに組み込めない(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なのでかなり効率化できた

参考

【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の信頼性を支えるエンジニアリングチーム

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

The Site Reliability Workbook: Practical Ways to Implement SRE

The Site Reliability Workbook: Practical Ways to Implement SRE

  • 作者: Betsy Beyer,Niall Richard Murphy,David K. Rensin,Kent Kawahara,Stephen Thorne
  • 出版社/メーカー: O'Reilly Media
  • 発売日: 2018/08/04
  • メディア: ペーパーバック
  • この商品を含むブログを見る

【15-B-7】無意味なアラートからの脱却 ~ Datadogを使ってモダンなモニタリングを始めよう ~

デブサミ2019【15-B-7】無意味なアラートからの脱却 ~ Datadogを使ってモダンなモニタリングを始めよう ~ #devsumiB - Togetter

Datadogの池山さん(実は珍しい名字だそう)。アジア圏の最初の社員。

  • 犬のロゴかわいい
  • でも社員はネコ派が多い
  • "Cattle, not pets"
    • ペットのようにひとつひとつ細かく見て分析するのではなく、家畜のように群れとして管理できる
  • 14 days free trialがある

www.datadoghq.com

日本語ドキュメントも完備

docs.datadoghq.com

参考

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

おまけ

今日読んだ(というか書かれた)個人スポンサーはいいぞという話。来年は検討しようかな…

blog.evangelism.jp

*1:テストがなければ0%ですけれど