メルカリさんで開催された『SRE-SET Automation Night』に行ってきました。
この勉強会は、SRE(Site Reliability Engineer)およびSET/SWET(Software Engineer in Test)な人を対象をした、"自動化"にフォーカスしたもの。
以下、雑なメモ。
Data processing, workflow and us ~How to manage automated jobs~
- @syu_creamさん。メルカリのSREチーム
- ログをBigQueryに送る部分を改善
- 統計
- オンメモリ処理だとメモリがつらくなってきた
- シーケンシャルに実行していたが時間がかかるので並列化したい
- 改善
- Full managed ETL(extract, transform, and load) serviceを使う
- Apache Airflowでジョブ管理
レビューのコストを削減するための施策
www.slideshare.net
- @tarappoさん。DeNAでSWET、iOS/Android Test Night主催
- レビューのコストが高いので、できるだけ機械に任せたい
- レビュー対象は色々あるが、今回はテスト観点のドキュメントの話
- ここで言う「テスト観点」は、対象プロジェクトにおいてテストで確認すべきポイントを機能単位にまとめたもの
- QAが書いている
- GitHubを使い、Pull Request(以下PR)でレビューを行っている
- 運用の問題。コメント数が最大174のものもできた
- 指摘を修正されてもチェックしきれない
- レビュアーとして途中参戦したくない
- どのPRをレビューすべきか判断できない
- PRの内容が記載されていない、タイトルにWIPがついたままでレビュー依頼されるのが一因
- Dangerで事前チェックすることで回避
- 文書の問題はtextlintでチェック
- 対象プロダクトの固有名詞辞書で表記ゆれのチェック
- ですます調、である調、弱い日本語の禁止(〜かもしれない、〜と思う)
- PRの前に各自textlintを流す(必須ではないけど、ほぼやってくれる)
- PRのコメントに"review"と書く → CIでtextlintとDangerが走る → okならレビュアーにmentionが飛ぶ
- JenkinsのGitHub Pull Request Pluginで、特定フレーズでキック
- Danger
- 内容のチェック
- タスクが全て完了しているか、textlintが通っているか
- 最終コミットがgreenになっているか
- 通ると、ラベル"In Review"がつく
- 導入後、表記ゆれ、typoが減った。PRが見やすくなった
- 今後の課題
Reliable Mobile Test Automation
www.slideshare.net
- @vbanthiaさん。DeNAでSWET→メルカリでSET
- Appium Docker DemoとかSTF Appium Exampleとか公開
- Test Automation Lift Cycle
- モバイルにおいて、自動テストだけを信じてリリースできるか?(会場では自動テストをやっている人は多かったが、信じられるか?の問に挙手した人は1人だけ)
- 機能が増えてくるとQAチームがパンクする。振り返りで"We need automation!"となる
- Development Teamから分割してSET/SWETなどに分けるケースが多い?
- ツール選定・導入は比較的簡単にできる
- たくさんテストを書く
- そのテストをリリースまで使うのが難しい。問題になるのは、
- Flaky tests(不安定なテスト。様々な要因で成功したり失敗したりするもの)
- Test execution environment(実機を含めたテスト実行環境)
- 結果、テストが信じられない。使われなくなり、メンテされず、捨てられてしまう
- Flaky Tests
- 原因として
- User interface issue
- Backend issue
- 3rd party service issue
- Hardware issue
- problem is not flaky test. 問題は、テストがflakyなことではなく、テスト実行中に何が起きたか我々が知らないこと
- 対策は"Record everything!"
- Screenshots, Video
- ADB logs
- Timestamp of each UI action and test assertion
- Test script logs
- Appium logs
- レポートの改善
- RSpec HTML Reporterが便利なので使ってほしい
- こちらも参照: About RSpec HTML Reporter - Mercari Engineering Blog
- 原因として
- Test Execution Environment
- Cloud Serviceが使えればベスト、誰でも使える環境
- 以前の発表、"Android e2e testing at mercari"を参照
- Google Cloud Storageにapkをuploadして、DockerでOpen STF、Circle CIでDocker imageビルド、テスト実行
- デモ
- Mobile test automationはチャレンジングだが不可能ではない
Magic Podの活用を具体的に考えてみた
www.slideshare.net
- 戸田さん
- Magic Podについて、Selenium IDEを使っていた層に向けたもの、という印象を持った
- コード書ける人、Excel+手動テストの人、という人たちがいて、その中間の層
- アプリが完成してから自動テストを作るのでなく、ワイヤーフレームから仮のテストケースを作っていけばQAも並列作業できるのでは?
- CLIもある。Travis CIでは検証した(TRIDENTさんのブログで公開)。Circle CIは検証中
Prometheusを導入した話
- 株式会社Nagisaの榎戸さん
- 監視にNagiosを導入。でも一台ずつ設定がめんどくさい
- Prometheus & Ansibleを導入
- Grafanaでビジュアライズ、Slackで通知
- Prometheusを2台使うのではでなく、PushProxを使う
- proxyみたいなもの
- 詳細はNagisaさんのブログで明日公開予定 → PrometheusでNATを越えよう! – 1万台のサーバを監視できると話題のPrometheusをGrafanaと組み合わせて導入した話~vol3~ | Nagisaのすゝめ
セキュリティ強化のための自動化
- @manabusakaiさん
- freeeでは人やお金に関する情報を扱っている。情報漏えいは厳禁だし、よく攻撃もされる。
- 1,000台のサーバをSRE 3人で見てるので、自動化で対応
- セキュリティパッチ、すぐ適用したいけど難しい
- 外部からの怪しい攻撃は自動的に遮断したい。攻撃されてから気づくことが多い?
- CodeBuildを使いAMI作成
- AWS WAFを使った攻撃の自動遮断
1人インフラ運用チームで、自動化の作業時間を確保するためにやっている(た)こと
- @katsuhisa__さん
- 定常的な運用業務の標準化
- 自分が突然死した場合のリスクが低減
- 業務移管が可能に
- 全手動と全自動の間、半自動
- 半自動を脳内でスキップできる人もいるけど、マニュアルを整備して半自動化する意味はある
- マニュアル作成サービス→ マニュアル作成ソフト・ツール Teachme Biz|動画で手順書を簡単作成
- ゼロコーディングでToilの周期を延ばす
- 定常的な業務が減る、コンテキストスイッチが減る
- 必要に応じて札束で殴る
Automation基盤提供のしかた
- @tnirさん
- 実行履歴が取れることが大事
- 実行タイミングを制御できること
- ナイトリービルド
- マニュアル実行
- イベントドリブン
- 自動再実行、マニュアル再実行
- 実行命令系との連携
- dev: SCMとの連携
- ops: Infrastructure as Code
- ジョブと変数の分離
- GitLab CI/CDを使っている
- 社内への普及活動
- 勉強会、Wiki
- 業務上は困ってないが、デザイン/パフォーマンスには課題。ほかも検証してみたい
所感
会場にSREな人は少なかったようですが(私も門外漢ですが)、"自動化"というキーワードでくくって広範囲な話が聞ける機会となり、とても面白かったです。
いずれも、導入から運用、改善のスパンが長くなる話なので事例そのものが貴重ですし、かつ今回は単に「試してみた」「導入してみた」を超えた話が聞けて大変ありがたいイベントでした。
第2回以降も(自動的に!)開催されそうな方向なので、期待して待ちます。