エンジニア１名によるサービス開発と運用 20140219devsolo@Speee
•
4 likes•3,362 views
少人数でのサービス運用についての話 サービス開発時の課題と対応 ステージごとの開発のバランスの取り方について
Recommended
More Related Content
Recently uploaded
Recently uploaded (12)
Featured
Featured (20)
エンジニア１名によるサービス開発と運用 20140219devsolo@Speee
- 3. who? • @EGMC • http://egmc.me/ • しごと • こじん ももクロAndroidアプリ http://momochro.me/ 14年2月21日金曜日
- 7. 今日話すこと • 少人数でのサービス運用についての話 • サービス開発時の課題と対応 • ステージごとの開発のバランスの取り 方について 14年2月21日金曜日
- 8. 今日話さないこと • 最新技術的なこと • 技術的な詳細（コードなし） • 大規模チーム開発っぽいこと 14年2月21日金曜日
- 10. アジェンダ • はじまり ローンチ前、背景 • つくる期 サービスローンチ∼１年 • 安定させる期 2年目∼ • 発展させる期 現在∼future 14年2月21日金曜日
- 12. 運営サービス • クラウドファンディン グプラットフォーム CAMPFIRE • 総支援額 約2億6000万 • 総プロジェクト数 約680件 2014年2月時点 14年2月21日金曜日
- 13. チーム（開始時） • デザイン • キュレーター • tech（ひとり） 14年2月21日金曜日
- 14. チーム（現在） • デザイン • 広報 • Growth • キュレーター（4名） • tech（ひとり） 14年2月21日金曜日
- 15. 環境 • Amazon Linux • PHP5.4 • CakePHP1.3 • apache2.2 • MySQL5.5(RDS) • redis(セッションストレージ) 14年2月21日金曜日
- 16. 背景(1) • CAMPFIREローンチ • 2011-06-02 • 株式会社ハイパーインターネッツ入社 • 2011-06-01 14年2月21日金曜日
- 17. 背景(2) • 元々作ってた人から引き継ぎ • 仕様書なし • 「アプリは出来てるから」って言われ てた • リリース直前にバグ対応 • 突貫でインフラ構築してリリース 14年2月21日金曜日
- 18. 背景(3) • 入社時のスキルセット • 前職はガラケーのポイントサイト • オレオレPHPフレームワーク • メジャーなPHPフレームワークは初 • ソシャゲの開発でAWS経験はアリ 14年2月21日金曜日
- 21. • まずは何から？ • サービスを作る体制を作る • 運用を作る 14年2月21日金曜日
- 23. 開発体制？ • タスク管理＆バージョン管理＆デプロイ • 情報共有 • ルールづくり 14年2月21日金曜日
- 24. 開発ツール • サービスを作るためのツール • 何を使うか？ • 自前、オープンソース、外部サービス 14年2月21日金曜日
- 27. 何故自作？ • とにかく早く構築する必要があった • 既存ツールは学習コストがかかる • 機能的に要件を満たしている • Webインターフェースが必要 • 要件に合わなくても手を入れやすい 14年2月21日金曜日
- 28. 要件を満たす • 社長がデザインもやるので勝手にデプ ロイ出来る仕組みが必要 • リリースするものを選べる仕組み • Webインターフェース 14年2月21日金曜日
- 29. 情報共有 14年2月21日金曜日
- 30. redmineのwiki • 細かく仕様は書かない • 見るべき箇所、気をつける点のみ • 着手したところから書いていく • 非エンジニアも使用 • 最初に教育(使い方と概念） • ストック情報、ルールを一箇所に 14年2月21日金曜日
- 31. ルール作り • コーディング規約 • PSRをベースに若干おおらかに • デプロイに関するルール • 文言修正レベルは通したい • ロジックが絡むかどうかが基準 • ルールはwikiへ、定期的に更新 14年2月21日金曜日
- 33. 運用を作る？ • サービスのサイクルに合わせた運用 ルール、体制、管理ツール作り • エンジニアだから∼というフェーズで はないので積極的に関わっていく • チェックリスト作りなど 14年2月21日金曜日
- 34. サービスのサイクル • 案件投稿 • →審査 • →素材の受け取り、フィードバック • →掲載作業 14年2月21日金曜日
- 35. 運用を作っていく • 「まずこうあるべき」というフローを 作る • 手持ちのツールで一本のフローを作る • 徐々に「機能」で置き換えていくこと で手離れ 14年2月21日金曜日
- 37. 何故redmine？ • 基本ツールはなんでも良い • 海外のisssue管理系ツールとかね • ただしAPIが利用出来ること • 「最小限のルール」からスタート • なんでもかんでもやろうとすると破綻 • 「時間管理」とか使ってない 14年2月21日金曜日
- 38. Excelはダメなの？ • スプレッドシート結構使ってます • 現在の状態は管理出来るが歴史は管理 しづらい（そういうツールじゃない） • 同時更新とかそういうの • 使いどころの問題ですね 14年2月21日金曜日
- 39. API大事 ! ! ! ! ! // -------redmineへ登録連携 ! ! ! ! ! ! // タイトル ! ! ! ! ! ! ! ! ! ! ! ! $redmine_title = "{$propdata['Proposal']['id']};{$propdata['Proposal']['title']}"; // 登録 ! ! ! ! ! ! ! ! 14年2月21日金曜日 ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! $response = $redmine->postIssue( ! array( ! ! CfRedmine::PARAM_PROJECT_ID => _CF_REDMINE_PROJECT_ID, ! ! CfRedmine::PARAM_TRACKER_ID => _CF_REDMINE_TRACKER_ID, ! ! CfRedmine::PARAM_SUBJECT => $redmine_title, ! ! CfRedmine::PARAM_DESCRIPTION => $bodytext, ! ) );
- 40. 管理ツール • よく使うものから作る • この場合「案件管理」 • なにはともあれ動くことが大事 • 運用に合わせて変更を加えていく • 足りない部分は文言で補足 14年2月21日金曜日
- 41. ユーザーサポート • すべてを作ろうとすると際限ない • お金に関わる部分から作る • 対応する機能を作るか、そもそも問い 合わせが来ないようにするか判断 • 機能をどこまで作りこむかはトレード オフ 14年2月21日金曜日
- 42. つくる期まとめ • サービスのフロー（つまり業務フ ロー）を一緒に作る • 将来的にシステムに置き換える想定は しておくが最初は手動 • サービスがまわることが大事 14年2月21日金曜日
- 45. • 安定させる？ • 運用に必要な機能の作り込み • スケール可能な安定したインフラ • 設計上の問題点の対応 • セキュリティの強化 14年2月21日金曜日
- 48. 管理ツール • 機能追加ですぐ作れるように定型化 • よく使う機能は作りこむ • 事故らないように作りこんでいく • 入力項目の制限 • ステータスに応じて操作を制限 14年2月21日金曜日
- 52. インフラ • 限られたリソースとのトレードオフ • 予算、時間（人） • 「絶対に落とすべきではない」かどう か 14年2月21日金曜日
- 54. 設計上の問題点 • リリース時に想定してなかったこと • 設計上の問題は負債として積み上がっ ていく • 時間が経つほど手を入れづらい • コア機能こそ手を入れていく 14年2月21日金曜日
- 55. 設計上の問題(1) • ユーザーが登録時のログイン方法しか 使えない • 複数アカウントの紐付け • 後でやると結構大変 • 追加テーブルを作ってデータ移行 14年2月21日金曜日
- 56. 設計上の問題(2) • 支援データと決済データの密結合 • 決済に失敗した場合などに困る • 決済システムの変更を行った際にま とめてテーブル構成を変更 14年2月21日金曜日
- 57. とはいえ • 基本的にはシンプルに設計しておいた 方が良い • ２つ以上の概念や詳細が一つのテーブ ルに同居してると危険 • この場合「決済」と「購入情報」、 「ユーザー」と「ログイン方法」 14年2月21日金曜日
- 59. セキュリティ • 基本的にこのあたり • XSS • セッション固定化、ハイジャック • SQLインジェクション • XSRF 14年2月21日金曜日
- 60. どこまでやるか？ • 基本的には粛々とやれば良い • どの程度の悪いことが出来るのか？ を想定 • 個人情報、お金への影響 • ただのイタズラ 14年2月21日金曜日
- 61. CAMPFIREの場合 • 初期は発送先等の保存機能なし • あんまり悪さ出来ない • 支援を勝手にやるとかそのレベル • 機能が増えるとできることも増える • 守るべきものが増えていく 14年2月21日金曜日
- 62. XSS対策 • とにかく起こりやすい • ユーザーの機能が増えるほどできるこ とが増える→リスクが増す • 基本は自動エスケープ • JSへの値に受け渡しは特に気をつける 14年2月21日金曜日
- 63. 安定させる期まとめ • 手動→自動 • 動いているから大丈夫、ではない • 既に動いている部分にも手を入れる 14年2月21日金曜日
- 66. • 数字を伸ばす • 効果測定 • サービスとしての付加価値 14年2月21日金曜日
- 70. ツール • 普通にGoogle Analytics • カスタム変数で属性追加 • 週次でレポート送信→軌道修正 • アプリ固有の情報はDBで • 案件情報はredmineAPI経由で取得し て集計 14年2月21日金曜日
- 73. インサイト機能 • よくあるユーザー向けの簡単な Analytics的なもの • プロモーション支援 • fluentd+Amazon EMRで実装 • 難しいことはそんなにしてません 14年2月21日金曜日
- 74. 付加価値 • なくてもなんとかなる機能 • なるべく勝手にまわるような仕組みを 作る • 効果測定を忘れずに 14年2月21日金曜日
- 75. future • ログ分析をもっといい感じに • アプリケーションログを使おう • 早いサイクルで軌道修正 • アプリケーションレベルでの自動化 • アプリレベルで運用をまわす • 人間がやるべきことをやろう 14年2月21日金曜日
- 77. ひたすら自動化 • 手動は基本的にミスる可能性がある • 自動化もエラーはありうるがそれは単 に不具合 • それぞれやるべきことに集中する • 開発、分析、営業 14年2月21日金曜日
- 78. トレードオフ • ステージごとにトレードオフを考える • サービスの段階で優先度は変わる • リソースは常に有限（マシンリソース、 人、お金） • 「十分なレベル」も変化する 14年2月21日金曜日