Download to read offline
YAPC::Asia2015
- 1.
- 2. 自己紹介 • masartz • http://search.cpan.org/ masartz/ •https://github.com/ masartz • VOYAGE GROUP adingo -> fluct
- 3.
- 4. 結論 • 言語が変わっても求められる事は変わらない • 言語に関わらずできること/しなければならない ことはある •無駄な部分はなるべくなくしていこう • そのために自分の持っている技術を使い、また その技術の幅を広げよう
- 5. 前提 • What sSSP? • What s fluct? • How Architecture Works?
- 6.
- 7.
- 8. 本日のお品書き 1. Perlの現場でやってた事を PHPの現場でもやった話 2. PHPの現場で書いたものを Perlにバックポートした話 3.Rubyの現場で暫定対応をPerlでやった話 4. まとめ
- 9.
- 10.
- 11.
- 12.
- 13. Perlの現場では？ • 古いライブラリで、社内のガイドラインに沿ってない ファイルがたくさんあった • Test::CodingStyle(https://github.com/mixi-inc/p5-Test- CodingStyle )という仕組みを作り、既存ファイルを blacklistに入れて分別するようにした • 新規分は必ずガイドラインに沿えるようになった • http://www.slideshare.net/masartz/ yapc2013-26481517/21
- 14.
- 15. この話のまとめ • 対象リポジトリ配下全てがPSR-2に沿った • 対応リリース過程で障害に繋がったケースはなし •大切な事は、明瞭な規約に沿う事にコードを 統一できたことではない • 人がやるべきではない作業を機械にやらせるよ うにした
- 16.
- 17. 共通していること • 開発者がcrontabをうっかり書きミスること 例）19時00分にだけ動いてほしい場合 誤： *19 * * * php hoge.php 正 : 0 19 * * * php hoge.php • cron.txt っぽいファイルで設定を管理している • crontabの解析用のライブラリが既にあることに よって少ない工数で、テストが書ける
- 18.
- 19. 何をしたか？どうなったか？ • crontabの設定をうっかりミスってしまい、 障害が起きてしまった • 書きミスがちょっとだけ防げるdoctest (orTest::Base)っぽいテストを書いた • テストが落ちることで、うっかりミスに気づけ るようになり、簡単な再発防止策となった
- 20. * 19 ** * php hoge.php ###prev 2014-12-31 19:00:00 ###next 2015-01-01 19:00:00 これだと、テスト落ちる
- 21. 0 19 ** * php hoge.php ###prev 2014-12-31 19:00:00 ###next 2015-01-01 19:00:00 これだと、テスト通る
- 22.
- 23. 10 19 ** * perl hoge.pl ###sample 2014-12-31 19:20:00 これだと、テスト落ちる
- 24. */10 19 ** * perl hoge.pl ###sample 2014-12-31 19:20:00 これだと、テスト通る
- 25. PHP環境 Perl環境 課題 開発者がcrontabをうっかり書きミスる 現状Cron Expressionがある Parse::Crontabがある 対応 Cron Expression を用いたテストファイル Test::Parse::Crontab::Simple 結果 うっかりミスに少しだけ気づきやすくなった
- 26. 何故Perlに移植したか？ • PSGI,Plack,plenv,Carton etc… •近年のPerlの成長は他言語からの流入が大きい • 他言語で得た知見をPerlに還元するため
- 27.
- 28.
- 29.
- 30.
- 31. 何をしたか？どうなったか？ • 入稿するJavascriptタグを多重登録してしまう オペレーションミスがしばしば起こっていた • 重複検知のための要件定義をPerlで行い、 定常運用版をRubyで書いた •重複が発生した場合、アラートメールが届き、 重複を解消できるようになった
- 32.
- 33.
- 34. この案件のキモ • 要件定義をできるだけ早めて、早く次のフェーズ に進むこと • 一旦現状をクリーンにしてから、異常があった 場合のみメールが発砲されるようにすること •現状を鑑みて、冗長体制かつ、少ないメンテナ ンスコストで運用できるようにすること
- 35.
- 36.
- 37. この話のまとめ • 現状、通知メールが来ると「おっ？」って 思える運用フローになっている • リリース後稼働しているRuby版は冗長な メンテナンス体制が取れている •案件の性質を理解し、より良い手段を取ること が大事であるということ
- 38. 全体のまとめ • 言語が変わっても求められる事は変わらない • 言語に関わらずできること/しなければならない ことはある •無駄な部分はなるべくなくしていこう • そのために自分の持っている技術を使い、また その技術の幅を広げよう
- 39.
- 40.
- 43.