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.

サービス運営からのアンチパターン Devlove甲子園2013坂部

1,543 views

Published on

サービス運営からのアンチパターン
Devlove甲子園2013坂部

当日に発表依頼され、自分って何か発表することあったかなぁと考えました。

私はあるサービスをスタートから見てきて、営業から 運用までやってきて、ここは運用のアンチパターンかなぁって部分を自分なりにピックアップしてきました

  • Be the first to comment

サービス運営からのアンチパターン Devlove甲子園2013坂部

  1. 1. サービス運用からのアンチパターン サービスの運用保守を4年間してきた中での経験 DevLOVE現場甲子園2013 三回裏 チーム守 @koudaiii
  2. 2. こんな人 • 元海岸沿いのSier • 企画から運用まで • TISMatsuriメンバー • Twitter: @koudaiii • Blog: http://koudaiii.hatenablog.com/
  3. 3. 2013年11月8日22時25分
  4. 4. えっ?
  5. 5. 本日は、新人デビュー戦です。
  6. 6. よろしくお願い致します!(`・ ω・´)ゞ
  7. 7. サービス運用からのアンチパター ン
  8. 8. サービスの企画から開発、営業、 運用、保守、サポート、契約の事 務までやっています。
  9. 9. あるサービスをスタートから見て きて、 運用について、ここはアンチパ ターンかなぁって部分を自分なり にピックアップしてきました
  10. 10. 1 運用者が作るスクリプトが増える 2 叩いたコマンドのログを正しく振り返り していない 3 ExcelでConfの丸コピ 4 バージョンと戦わない 5 説得する相手を間違える 6 ログを正しく運用しない 7 ツールの選定を正しくしていない 8 とりあえず動いたからやってみた 9 サービスのバージョン2を考えていない 10 「運用者が学ばない世界がサービスを壊 す」
  11. 11.
  12. 12. 運用者が作るスクリプトが増え る
  13. 13. 突然の障害連絡で現場で見たもの
  14. 14. ●●_watcher.sh stop_start_●●.sh
  15. 15. cronに指定されておりました。
  16. 16. 三年間一度も実行されずに、 実行されたタイミングで。。。う わあぁ
  17. 17. タイムスタンプが2010年10月29日 Σ(゚Д゚; <配属されたくらいか
  18. 18. まだシステムが安定していない状 態だった時 暫定的に、プロセスを自動で起 動するように仕込んだものと思わ れる。
  19. 19. 実行されなかったのはDeveloper側 で、すでにコード修正を行って いたため。
  20. 20. その場で対応したものはDeveloper と連携しましょう。 暫定対応は漏れる可能性がありま す(リポジトリに入らない可能性 有り)
  21. 21. なぜなぜ分析や振り返りする際に、 運用/保守しか出席メンバーがい ない場合、ご注意
  22. 22.
  23. 23. 叩いたコマンドのログを 正しく振り返りしていない
  24. 24. 特に障害時
  25. 25. SLAもあり、 早めに対応することは非常に大事、 切り分けポイントとその時使用 した際のコマンドは振り返りに必 要
  26. 26. あれ?前どうやったっけ?
  27. 27. その場で対策をメモ帳とかで書き ながらやるのが一番よさそう。 ちなみに紙はたまに消える
  28. 28. 属人化する可能性のもと。 最終的に内弁慶になって、 俺が承認するまでダメだ。 となる可能性があるので、ご注意
  29. 29.
  30. 30. ExcelでConfの丸コピ
  31. 31. 詳細に記載あるけど、 「なぜ?」がない時があり、 なんとなくこれが最適だと思っ ちゃう。
  32. 32. 「これ実績あるからキリッ」 と言われた時は、注意。
  33. 33. 似た問題で、手順書も。 思考が停止する可能性があり、 ご注意を
  34. 34.
  35. 35. バージョンと戦わない
  36. 36. Rails2系から3系の移行 今まで動いているのに、なんで?
  37. 37. 早めに対応行わないと、 そのバージョンを扱うエンジニア はいなくなる。(特にRuby) またサポート切れるとわかった時 点では、もう手遅れの可能性が。。
  38. 38. 塩漬けにするか、バージョンアッ プを行うかはしっかり軸を持たな いと取り返しがつかない
  39. 39. サービスを育てていく場合、 プロダクトオーナーも含めて、一 緒に取り組まないとなかなか進ま ない
  40. 40. オーナーから見たら、売れる機能 を作ってもらったほうが効率がよ く見えるし、運用もめんどくさい ことしなくていいし。 コードの影響が少ないうちにバー ジョンアップをするクセを付けな いとなかなか身につかない
  41. 41. 5
  42. 42. 説得する相手を間違える
  43. 43. 日々、毎回のリリースの範囲と か、日程調整とか、品質とかで 色々調整が有りますが
  44. 44. Developerと争ってもしょうがな い
  45. 45. その裏には、Businessの戦略があっ たり、お客様が本当に困っていた りと背景があるはず
  46. 46. 直接相手に聴いてみる、または担 当者から事情を聴き、
  47. 47. 本当にやるべきなの? 急ぎなの? あちらを立てたら、こちらは立た ずにならない?
  48. 48. このサービスってどうあるべきな の?
  49. 49. Developerと同じベクトルを向いて 本来のお客様にフォーカスしない と 変に調整、判断、承認が必要に なってしまう
  50. 50.
  51. 51. ログを正しく運用しない
  52. 52. スタートアップ時は利用者が少な いので、ログを目で見ることが出 来る
  53. 53. 時がたち、気がついたら もうログは目で追えない。
  54. 54. 原因不明=監禁 サーバー室マジ寒い。 目で追えないし。(ってか昨日から いるし。
  55. 55. 早いうちに整形する仕組みが必 要
  56. 56.
  57. 57. ツールの選定を正しくしていな い
  58. 58. なんか流行ってるし使ってみる。 ・・・・ あれ?これスケールアップしない の?
  59. 59. 流行りをいきなり使うのは、 全部が全部悪いとは思いません が、
  60. 60. • このツールを使ったときと使わなったと きの違いは? • ツールを用いた場合の結果の信頼性は? • ツールを用いて良い作業は? • ツールを用いることができない部分の特 徴は? • 人間の判断を必要とする作業の特徴は? • 最も効果を発揮できる作業の特徴は?
  61. 61. 優位性と限界を知って、 効果的な利用方法を考える。
  62. 62.
  63. 63. とりあえず動いたからやってみ た
  64. 64. Index貼っていない
  65. 65. DELETEの後に すぐINSERTをするtrigger
  66. 66. スケールしないサーバー
  67. 67. 3年後
  68. 68. (ry
  69. 69. Commitの履歴を確認! Slow-Queryを確認! Show innodb statusを確認! すぐ! 各Tableに10万行来たらどうな る!? あと一回作ってテスト通ってそ れっきりは落とし穴になる可能性 大
  70. 70. スタートアップ時と三年後では もはや違うサービス
  71. 71.
  72. 72. サービスのバージョン2を考えていな い
  73. 73. サービス開始してから、 2〜3年の時に、 サービスのバージョン2を出す時が来 ます(リニューアル)
  74. 74. ログ等の解析やヒアリングをせず に 2-3年を迎えると、
  75. 75. ユーザーのツボ いらない機能 ストレスポイント がわからない
  76. 76. 画面のデザインを変えるだけの バージョン2を迎えると
  77. 77. リニューアルの期待を裏切り サービスをあともめることなく終 わらせていく消化試合にな る。。。
  78. 78. 最後に、
  79. 79. 10
  80. 80. 「運用者が学ばない世界がサービスを壊 す」
  81. 81. サービスをスタートアップから やってきて思ったことが
  82. 82. 今までやってきたものを変えてい く 勇気は非常に大変
  83. 83. 運用者は内弁慶になりやすく
  84. 84. 変えていく勇気がなかった時
  85. 85. 今まで動いているものに固執す る
  86. 86. その固執が、Developerを殺し、プ ロダクトオーナーを殺し、サービ スを殺す
  87. 87. Ops「今のバージョン(3年前)でなんとかしてくだ さい。」 Dev「・・・。」
  88. 88. Ops「このバージョンでの実績がありません。」 Dev「・・・。」
  89. 89. 障害をいくつも経験してきた 運用者の 「これ以上の機能追加は危険で す。」 というセリフは妙に説得力がある
  90. 90. その言葉はサービスの成長を止めてしまう
  91. 91. Businessの成功とエンドユーザーが 幸せになるには 基板であるインフラ作りが大事
  92. 92. 自分自身を固執せず 変える習慣が必要
  93. 93. まずは、今のRelease Notesを読むこ と、 トレンドのツールやミドルウェア を学ぶ
  94. 94. ええと思ったら、やってみよ う。
  95. 95. ご静聴ありがとうございました。

×