Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Web屋の運用その極意

2,487 views

Published on

社内勉強会発表資料から公開してはいけないものを抜いたもの

2016/10/13 一部文言を修正しました。

Published in: Technology
  • Be the first to comment

Web屋の運用その極意

  1. 1. Web屋の運用その極意 shigemk2 2016/9/13
  2. 2. 職歴  ニート  オンライン英会話サービス  ソシャゲ  アフィリエイトサービスプロバイ ダ  CyberZ
  3. 3. 現在手かげている プロジェクトB(仮)
  4. 4. リリース後半年経過した プロジェクト
  5. 5. でもシステムは破綻仕掛けていた
  6. 6. よくある話
  7. 7. よくある話 1.プロダクトが当たる 2.技術的負債がひどくなる 3.リプレイス
  8. 8. 技術的負債  読みにくいコード  テストコードがない  文書がない  拡張性がない
  9. 9. リプレイス  使用言語の変更  フレームワークの変更  オンプレ→クラウド
  10. 10. よくある話 1.プロダクトが当たる 2.技術的負債がひどくなる 3.リプレイス
  11. 11. よくある話 出典: https://www.fastcompany.com/1825877/5-things-i-learned-about- entrepreneurship-y-combinators-paul-graham
  12. 12. 技術的には 出典: https://www.fastcompany.com/1825877/5-things-i-learned-about- entrepreneurship-y-combinators-paul-graham このあたりで リプレイスを決心 リプレイス
  13. 13. 他プロダクト比較 社名 変更 リリースから リプレイスまで Twitter Ruby on Rails→Scala 5年 ドワンゴ PHP??→Scala 10年以上(継続中??) ビズリーチ Java→Scala 6年(別プロダクト) 某社A CakePHP→Ruby on Rails 3年(頓挫) 某社B オンプレ→クラウド C/Java→Scala 約10年
  14. 14. よくある話 リプレイスを決心するのに だいたい2、3年
  15. 15. ではうちのプロジェクトは
  16. 16. 6ヶ月
  17. 17. 何が問題だったのか(設計/開発) 後から考えたら選んだ理由がよくわからないラ イブラリ/ミドル/フレームワーク 慣れない中でScalaを選んだ ライブラリがあるのに自前実装 implicit hell 拡張性/保守性の低いソースコード JOINだらけのSQL リリース後の運用が考慮されてない設計(後述) 自分のコーディング力
  18. 18. 何が問題だったのか(運用) 頻繁に本番DBに直接投げられるSQL→トラブル データ不整合と修復→遅れ ドキュメントが仕様書のみ→遅れ 当人しか知らない秘伝のタレ→遅れ 登録データが多すぎ + 手作業→遅れ リリースしてもバグが発生して、バグを修正し ても別のバグが出て…→遅れ 管理されない差しこみタスク→トラブル
  19. 19. 新規プロジェクトのカルマ
  20. 20. よくある話その2: ビジネス要求と 技術的な要求の大幅な乖離
  21. 21. 要約すると
  22. 22. サービスを停止してでも リプレイスしたい vs とにかく使ってもらいたい
  23. 23. よくある話 出典: https://www.fastcompany.com/1825877/5-things-i-learned-about- entrepreneurship-y-combinators-paul-graham
  24. 24. 技術的な流れ 出典: https://www.fastcompany.com/1825877/5-things-i-learned-about- entrepreneurship-y-combinators-paul-graham このあたりで リプレイスを決心 リプレイス
  25. 25. よくある話 出典: https://www.fastcompany.com/1825877/5-things-i-learned-about- entrepreneurship-y-combinators-paul-graham リプレイスしたい! もっと売りたい!
  26. 26. 各人正しいことを 言ってるけど、 結局何も進まない
  27. 27. これ、前に見たことあるで!
  28. 28. プロジェクトが破綻するパターンや!
  29. 29. 破綻とは(一般論) プロジェクト終了 身売り同然の株式売却 会社の合併吸収 倒産
  30. 30. よくないのはわかったので、 次どうするか考えます
  31. 31. アーキも実装も 壊滅寸前な場合、我々は どうしたらいいのか?
  32. 32. 対策 1.サービスを完全ストップしリプレイス 2.サービスは続けてリプレイスしない
  33. 33. 対策 1.サービスを完全ストップしリプレイス 2.サービスは続けてリプレイスしない 3.サービスを続けてリプレイスもする
  34. 34. 結構難易度の高い事案 1.リプレイス前のシステムをベースに保守 運用 2.高いビジネス要求 3.開発チームに運用タスクを流さない
  35. 35. 誰がメインで運用をやるの?
  36. 36. 自分
  37. 37. 合言葉は「ウンヨウガンバル」
  38. 38. 自分からの各種提案と実績  マイクロドキュメント(DocBase / QiitaTeam)  CI/CD(Rundeck + CircleCI)  Rundeckによる自動化  Backlogによる運用タスクの管理  かんばん + ホワイトボード(運用チー ム)
  39. 39. 運用のための自動化は重要
  40. 40. やっていること(開発チーム)  クリーンアーキテクチャ  spray→akka-http  オンプレ→クラウド + ECS  digdag  CI/CD(Rundeck + CircleCI)  fuentd → ElasticSearch → Kibana
  41. 41. 重要なのは、 如何にして開発チームのリソースを 開発に集中させられるか
  42. 42. 合言葉は「ウンヨウガンバル」
  43. 43. メリット  ビジネスサイド側からの窓口一本化  誰に聞けばいいの??がなくなる  開発チームはほぼ開発に集中できる  ビジネス的に何をやっているのか、何 を動かしているのかがわかる
  44. 44. デメリット  自分のリソースが間に合わない  DevOpsという時代の流れから逆行  モチベーションが上がらない(一般論)
  45. 45. よくある保守運用のモチベ問題  ルーチンワークが多い  新しい技術に触れない  下手をするとコードが全く書けない  しんどいわりに評価されづらい
  46. 46. よくある保守運用のモチベ問題 へのアプローチ  まずつまらない仕事であることを認めるこ と  認めた上で何をしたら面白くなるかを考え ること
  47. 47. おすすめ書籍
  48. 48. どうやってモチベを上げるのか  自分でも開発しに行くスタイル  自分で直せそうだったらさくっとPR  ドキュメントがなかったら書く  ビジネス的な数字を意識する  数字が上がるとテンションが上がる  やっていることを理解してもらうために社 内勉強会とか日報とかでアピールする
  49. 49. よかったこと  自分たちが今なにをつくっているのかがわ かったこと  うまくいったらやっぱり楽しい
  50. 50. 課題  迅速な対応がまだ出来てない  人が増えた時に対応できるほどドキュメン トが充実してない  まだ自動化できてないところがある
  51. 51. まとめ  作っていくうえで運用こそ重要  (やりたい人は少ないだろうけど…)  重要だけど大変だし面白くないのをどう やって面白くしてくかはすごく大事
  52. 52. ありがとうございました!
  53. 53. スペシャルサンクス DOさん  Mさん  草加雅人  仮面ライダーシザース  巴マミ  木場勇治  時津風  魔法つかいプリキュア  仮面ライダークウガ  ペニーワイズ  チームの皆様

×