km_output

お勉強と趣味のアウトプット

【新宿・代々木】納涼肝試し! WEBサービス運用の怖い話 RAKUS Meetup Tokyo #4に参加してきた

【新宿・代々木】納涼肝試し! WEBサービス運用の怖い話 RAKUS Meetup Tokyo #4

に参加してきたので自分用にまとめる。

イベント概要

日時:2019/8/28(水) 19:00-21:00

開催趣旨:ラクス社のこれまでのサービス運用事例から肝が冷えるような事例を共有する

rakus.connpass.com

障害対応と対策

下西章王さん

資料:

speakerdeck.com

にはちの法則(パレートの法則

障害の8割を生み出しているのは上位2割の原因では?

→共用レンタルサーバにおいては、スパム配送による障害発生がトラブルの9割。

スパム配送の原因と対策
  • 顧客のメールアカウントがクラックされた

パスワード強度が低い

⇒パスワードポリシーの設定、ロックアウト値の設定(○分以内に○回失敗したらはじく)、1時間あたりの送信数上限を設定

  • スパム配送プログラムが配置されてしまう

9割以上がWordPressを使用し、特定の場所(wp-content/uploads/~~)にプログラムを配置

.htaccessphpが動かないようにする

アクセス集中対策
  • mod_bw

Apacheのモジュール。帯域制限、接続数上限などを変えられる

実際にあった怖い話・物理故障

現在はハードディスク(データが入っている)に対しRAID10を適用。

RAID1を使用していた頃の話。

両方のディスクでエラーが出ていたためリビルドができない(データ復旧できない)可能性があった

障害対応はつきもの

日頃の予行練習等が大切

CS奮闘日記 バグと開発とわたし

木村明日香さん @a_suka1914

資料:

speakerdeck.com

CSチームの仕事
  • 新規顧客の導入支援

  • 既存顧客の問い合わせ対応

バグとの出会い方
  • リリース前のチェック or お客さんから教えてもらう
バグの周知文面
  • 分かりやすく・影響がない顧客には心配させないように伝える!

→実例の紹介(※詳細は掲載NG)

開発とのかかわり方
  • トラブル対応を開発から押し付けられているのではなく、役割分担をしていると考える

→実例の紹介(※詳細は掲載NG)

  • カスタマーサクセスはみんなで作るもの

  • 各部署が協力することが大切

※バグを責めるのは間違い!

安定した運用ができるまで

見形親久さん

資料:

speakerdeck.com

立ち上げた運用チームの方針
  • 運用の対応を最優先

  • 他部署とのやり取りは運用チームを窓口にする

  • 速度優先のため属人化を許容

具体的な業務
  • 顧客からの問い合わせ対応

CS部門からの技術的な質問への回答

  • 障害/運用トラブルの対応

対応方針の策定、関係部署のコントロール

  • リリース作業対応

スケジュール策定、進捗管理など

  • 個別対応案件

他部署からの相談(不定形作業)

運用の課題

運用は回るようになったが属人化から脱することが難しい

→サービス関係者が数倍に増えたとき、

開発部内の変化
  • チーム同士が疎遠に

チームが大きくなることでコミュニケーションが減少

  • スキルにばらつきが出る
属人化の弊害が顕著化

ルールが不明瞭でよく分からない(誰に聞くか、情報がどこにあるか)

障害発生事例

作業ミスでサービス停止、機能停止などなど・・・

→原因

  • レビュー不足

  • 説明不足(言葉の定義に認識齟齬がある)

  • コミュニケーション不足(チーム同士の作業内容の把握不足)

対策
  • 日時のMTG

  • レビュー体制の整備

  • 不満・要望をぶつけ合い課題の洗い出し

  • チャットルーム開設

  • 対応フロー確立

  • 振り返りMTG設置

まとめ
  • 普段のコミュニケーション、雰囲気づくり

  • ルールの明確化

最低限必要な品質を定め、誰でもできるルールを作る

作ったルールを目に見えるところに掲げ、全員の共通意識にする

  • 振り返り

障害対応などの記録は残し、改善に繋げる

PostgreSQL:終わらないAnalyze

rugger-srさん

アプリケーションの挙動

アンケートシステム:

アンケートの質問項目が決まっていない

作るごとにテーブル、カラムが増える

(リアルタイムでテーブル作成)

発生した問題1

クエリが遅い

→Analyzeを実行したところ速度が改善したため、定期ジョブでAnalyze実行

発生した問題2

Analyze自体が重くなっていた

→テーブル数40万以上になっており、根本対策を検討中・・・。

複数のDBに分ける、などなど・・・

エンジニア募集中!とのこと。

感想

  • 作業影響を認識齟齬なく伝えることの大切さ。

リリースに関わる事柄は特に注意して、こちらが心配している作業影響、知りたいことを正確に伝えようと思った。

特に経験が浅い人、普段の会話があまりない人に対しては配慮しないと伝わらないだろうなあとしみじみ。

  • 社内コミュニケーション不足だから今回のLTは刺さった。

全社員が一ヵ所で働いているわけではなく、slackも公式に導入されているわけではなく。

同期でもお互いに何の業務をしているか把握していない。

ただ抜本的な対策が特に思い浮かばない。今の状態で仕事回っているのもヤバい。