社内勉強会発表資料から公開してはいけないものを抜いたもの 2016/10/13 一部文言を修正しました。

1. Web屋の運用その極意
shigemk2
2016/9/13

2. 職歴

ニート

オンライン英会話サービス

ソシャゲ

アフィリエイトサービスプロバイ
ダ

CyberZ

3. 現在手かげている
プロジェクトB(仮)

4. リリース後半年経過した
プロジェクト

5. でもシステムは破綻仕掛けていた

6. よくある話

7. よくある話
1.プロダクトが当たる
2.技術的負債がひどくなる
3.リプレイス

8. 技術的負債

読みにくいコード

テストコードがない

文書がない

拡張性がない

9. リプレイス

使用言語の変更

フレームワークの変更

オンプレ→クラウド

10. よくある話
1.プロダクトが当たる
2.技術的負債がひどくなる
3.リプレイス

11. よくある話
出典: https://www.fastcompany.com/1825877/5-things-i-learned-about-
entrepreneurship-y-combinators-paul-graham

12. 技術的には
出典: https://www.fastcompany.com/1825877/5-things-i-learned-about-
entrepreneurship-y-combinators-paul-graham
このあたりで
リプレイスを決心
リプレイス

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. よくある話
リプレイスを決心するのに
だいたい2、3年

15. ではうちのプロジェクトは

16. 6ヶ月

17. 何が問題だったのか(設計/開発)
後から考えたら選んだ理由がよくわからないラ
イブラリ/ミドル/フレームワーク
慣れない中でScalaを選んだ
ライブラリがあるのに自前実装
implicit hell
拡張性/保守性の低いソースコード
JOINだらけのSQL
リリース後の運用が考慮されてない設計(後述)
自分のコーディング力

18. 何が問題だったのか(運用)
頻繁に本番DBに直接投げられるSQL→トラブル
データ不整合と修復→遅れ
ドキュメントが仕様書のみ→遅れ
当人しか知らない秘伝のタレ→遅れ
登録データが多すぎ + 手作業→遅れ
リリースしてもバグが発生して、バグを修正し
ても別のバグが出て…→遅れ
管理されない差しこみタスク→トラブル

19. 新規プロジェクトのカルマ

20. よくある話その2:
ビジネス要求と
技術的な要求の大幅な乖離

21. 要約すると

22. サービスを停止してでも
リプレイスしたい
vs
とにかく使ってもらいたい

23. よくある話
出典: https://www.fastcompany.com/1825877/5-things-i-learned-about-
entrepreneurship-y-combinators-paul-graham

24. 技術的な流れ
出典: https://www.fastcompany.com/1825877/5-things-i-learned-about-
entrepreneurship-y-combinators-paul-graham
このあたりで
リプレイスを決心
リプレイス

25. よくある話
出典: https://www.fastcompany.com/1825877/5-things-i-learned-about-
entrepreneurship-y-combinators-paul-graham
リプレイスしたい！
もっと売りたい！

26. 各人正しいことを
言ってるけど、
結局何も進まない

27. これ、前に見たことあるで！

28. プロジェクトが破綻するパターンや！

29. 破綻とは(一般論)
プロジェクト終了
身売り同然の株式売却
会社の合併吸収
倒産

30. よくないのはわかったので、
次どうするか考えます

31. アーキも実装も
壊滅寸前な場合、我々は
どうしたらいいのか？

32. 対策
1.サービスを完全ストップしリプレイス
2.サービスは続けてリプレイスしない

33. 対策
1.サービスを完全ストップしリプレイス
2.サービスは続けてリプレイスしない
3.サービスを続けてリプレイスもする

34. 結構難易度の高い事案
1.リプレイス前のシステムをベースに保守
運用
2.高いビジネス要求
3.開発チームに運用タスクを流さない

35. 誰がメインで運用をやるの？

36. 自分

37. 合言葉は「ウンヨウガンバル」

38. 自分からの各種提案と実績

マイクロドキュメント(DocBase /
QiitaTeam)

CI/CD(Rundeck + CircleCI)

Rundeckによる自動化

Backlogによる運用タスクの管理

かんばん + ホワイトボード(運用チー
ム)

39. 運用のための自動化は重要

40. やっていること(開発チーム)

クリーンアーキテクチャ

spray→akka-http

オンプレ→クラウド + ECS

digdag

CI/CD(Rundeck + CircleCI)

fuentd → ElasticSearch → Kibana

41. 重要なのは、
如何にして開発チームのリソースを
開発に集中させられるか

42. 合言葉は「ウンヨウガンバル」

43. メリット

ビジネスサイド側からの窓口一本化

誰に聞けばいいの？？がなくなる

開発チームはほぼ開発に集中できる

ビジネス的に何をやっているのか、何
を動かしているのかがわかる

44. デメリット

自分のリソースが間に合わない

DevOpsという時代の流れから逆行

モチベーションが上がらない(一般論)

45. よくある保守運用のモチベ問題

ルーチンワークが多い

新しい技術に触れない

下手をするとコードが全く書けない

しんどいわりに評価されづらい

46. よくある保守運用のモチベ問題
へのアプローチ

まずつまらない仕事であることを認めるこ
と

認めた上で何をしたら面白くなるかを考え
ること

47. おすすめ書籍

48. どうやってモチベを上げるのか

自分でも開発しに行くスタイル

自分で直せそうだったらさくっとPR

ドキュメントがなかったら書く

ビジネス的な数字を意識する

数字が上がるとテンションが上がる

やっていることを理解してもらうために社
内勉強会とか日報とかでアピールする

49. よかったこと

自分たちが今なにをつくっているのかがわ
かったこと

うまくいったらやっぱり楽しい

50. 課題

迅速な対応がまだ出来てない

人が増えた時に対応できるほどドキュメン
トが充実してない

まだ自動化できてないところがある

51. まとめ

作っていくうえで運用こそ重要

(やりたい人は少ないだろうけど…)

重要だけど大変だし面白くないのをどう
やって面白くしてくかはすごく大事

52. ありがとうございました！

53. スペシャルサンクス
DOさん

Mさん

草加雅人

仮面ライダーシザース

巴マミ

木場勇治

時津風

魔法つかいプリキュア

仮面ライダークウガ

ペニーワイズ

チームの皆様