Slackを導入しよう

1. を導入しよう
社内向け ２０１４/０
８/０７

2. とその前に、前提知識が必要です
・「情報」は大きく分けて２種類
┗ストック情報(永続的に記憶/記録の必要がある情報)
┗フロー情報(事案が終了次第流して(忘れて)よい)
・Slack はフロー情報を扱います。

3. Slack ?
・メッセージ通知に特化した外部サービスです

4. Slack ?
・メッセージ通知に特化した外部サービスです
・エンジニア向けの外部サービスとの連携がべんり～
- GitHub / Hubot / Heroku / Jenkin / New Relic / and so on

5. Slack ?
・メッセージ通知に特化した外部サービスです
・エンジニア向けの外部サービスとの連携がべんり～
- GitHub / Hubot / Heroku / Jenkin / New Relic / and so on
・外部連携していればメッセージが自動的に届いてべんり
～
- アプリケーションアラート通知
- アプリケーションアナリティクスサマリー通知
- コードレビューや継続的インテグレーションなど
断続的業務の起点と終点を通知
・モバイル版アプリがあっていつでも見れますねー

6. Slack 導入の目的？
・さまざまな情報が Slack の #チャンネルを変えるだけで
見られる(あのサイトいったり、あのアプリ立ち上げた
りを解消)
・メッセージ通知から素早いトラブルシューティングをし
よう
・(サーバ)パフォーマンスサマリーレポートから
未来予想をして予め危機を回避しよう
・自動化された会社内部のシステムと連携して
業務のサイクルを短くしよう
(これから自動化されたシステムを構築していきます)

7. Slack 導入の目的？
・Slack に通知メッセージが集まると
通知されたメッセージに対して、この課題どうしようか
と
Slack 上で(エンジニア語で話す場合に限り)チャットが
開始されると流れと時間がわかりやすいよね
例１) New Relic からサーバパフォーマンスのレポートが通
知されて → サーバスケールアウトが必要だね！
例２) Crashlytics からネイティブアプリが突然死したレ
ポートが通知されて・・・原因が分かったから直そう！
例３) 本番環境にデプロイしよう！(Slack 上で deploy
production(←例) としゃべるだけでデプロイされる)

8. Slack 導入の注意点！
・Slack上で扱われるメッセージ(chat)はフロー情報を扱う
こと！
「情報」は大きく分けて２種類
┗（X）ストック情報(永続的に記憶/記録の必要があ
る情報)
┗(○)フロー情報(事案が終了次第流して(忘れて)よい)
┗(○)両方の性質を持つ
ストック情報は永続的に保存されることが必要ですので、
Redmine Wiki / NAS /外部サービスなどに保存しましょう。
・エンジニア同士の会話のみ取り扱うように！
他職種(役割)との会話はいままで通り Skype でしましょ
う

9. Slack から自動化システムに通知？
・システムにデプロイの指示を出そう
- 本番環境にデプロイしよう
- ステージング環境にデプロイしよう
┗サーバコンテンツ ＆ DeployGate ＆ TestFlight
- メンテナンスモードに突入/解除しよう
- サーバをスケールアウトしよう
など

10. 自社アプリケーションからSlack に通
知？
デバッグ効率とリリース後の不具合対応速度の向上を目指
して
・サーバアプリ編
- httpd エラーログサマリーを Slack に通知しましょうか
- MySQL スローログサマリーを Slack に通知しましょう
か
(New Relic で十分か？)
(ElasticSearch + Kibana3 でも見れるようにしておきま
す)
・ネイティブアプリ編
- Crashlytics 組み込んでクラッシュレポートを

11. メッセージ全体図
業務連絡
サーバパフォーマンスア
ラート
デザイン/コードレ
ビュー
ネイティブアプリクラッシュレ
ポート
CI 待ち受
け
デプロイ
サーバアプリアラー
ト
エンジニアチャット
SlackAPI

12. 導入
いかがでしょ？