我不认为听到ShuttleCloud使用Slack会感到惊讶。 它已成为我们日常工作流程中的主要沟通工具之一，我们对此感到非常满意。 我最近遇到的一些人对它有一些负面的体验 ，并询问我们如何如此广泛地使用它。
我必须承认，我们花了一些时间才能到达目前的状态。 此外，我们还遇到了其他公司遇到的一些问题，例如充斥着消息和关键信息的渠道不被所有人阅读。 在这篇文章中，我们想提供一些提示和重点，以帮助我们立即使用Slack ，以防它们对您有用。
这不是一成不变的，因此我们可以迭代使用Slack的方式。 也许将来使用其他方法对我们更好。 而且， 我们仍然是一个小团队 ，因此一旦有更多的人参与，我们拥有的某些渠道可能就无用了，但是当我们解决这个问题时，我们将解决它。
如您所见，我们喜欢为每个目的使用一个通道的范例，这导致我们创建了一些单一通道。 我们甚至为特定主题或讨论创建临时渠道，以使上下文和数据清晰独立。 这是我认为最重要的渠道清单。
开发团队的渠道
我将从工程团队在日常工作中使用的渠道开始列出该列表-不仅用于技术资料，还用于内部组织或沟通。
#dev
这是开发团队的第一个也是主要的渠道 ，我们在这里讨论技术问题或仅涉及工程团队的日常问题。 例外情况是与开发团队有关的所有关键决定和重要声明。
我们不希望度假的人回来后能赶上这个频道，因为这可能要花几个小时（甚至几天！）。
#dev_announces
正是在这里发布有关团队的重要信息。 团队中的每个人都必须了解最新信息并了解此渠道。 为了避免泛滥， 它不是讨论和聊天的渠道 ，仅是#dev的声明和重要内容在这里放置。
#daily_learning
如果您在Twitter上关注@ShuttleCloudEng，您已经知道我们共享一些文章，并且每天进行讨论。 （如果您不关注我们，则应该！：））这是我们内部建议文章的渠道，同意讨论哪些文章并确定会议时间。
＃假期
如果某个团队成员想请假几天，他/她将使用此渠道将其传达给团队。 为了能够休假，开发人员必须检查那些团队成员确实在那些日子里工作，并且有自己的替补人员。 在此通道中，可以在提出正式休假请求之前对所有这些进行协调。
＃警报
在这个频道中，我们建立了与PagerDuty的集成（我们将其用于待命工程师）。 结果是， 每次触发警报时，它都会出现在此处 。 我们都将该频道的通知级别设置得很高，因此我们避免在此处聊天，而仅对触发的警报进行评论，提及或更新。 另一个用例是，如果团队中的任何人手动检测到任何服务的可能/潜在的严重故障，也将在此通道中进行通信。
#alert_discussion
当警报需要讨论或进行调查时，这是共享和讨论所有内容的渠道。 我们不为此目的使用#alerts，因为我们希望避免在同时发出警报时产生不必要的噪音。
#deploys
该渠道的主要目的是宣布将部署带有所有必要信息的设备，并要求“开绿灯”以继续进行部署。 slackbot在两个渠道中进行一些自动化，这是一个。 首先，我将解释我们过去的做法，因为我们第一个没有自动化的方法很有趣。
首先，每个部署请求都是使用包含以下详细信息的模板手动宣布的：
- “ 什么 ”：要部署的服务
- “ Where ”：受部署影响的项目，环境
- “ 何时 ”：部署时间
- “ 为什么 ”：简要说明要部署的更改
- “ 任务 ”：引用要修正的错误修正，更改和功能的Jira问题代码
- “ 风险 ”：部署失败的后果（例如，服务中断以及回滚的难易程度）
要继续进行部署，团队中的某个人必须批准它（通常是一个了解受影响组件的人，如果出现问题可以提供帮助）。 通过手动说“ OK”或“ go”即可完成批准 。
批准后，部署人员负责根据部署进度更新通道，并在部署和测试后进行确认。
目前，我们已经使用slackbot自动化了审批和通知流程。 每个项目都有一些团队成员被分配为最了解该项目的成员，或者在某些情况下可以提供帮助的团队成员。
slackbot需要项目的选定团队成员的批准，他们会使用thumbsup / thumbsdown表情符号来批准，而不是在频道上进行回复。 不需要休假或不工作的团队成员的批准，这是这些团队中不止一个人的原因之一。 在下图中，有一个部署示例：
- 明确提及需要批准的团队成员，因此，如果他们需要采取行动，他们会收到Slack通知。
- 机器人会计算票数，如果有任何表情符号表情符号，部署将被拒绝。 如果所有团队成员都同意，则部署将获得批准。
- 该漫游器会将批准过程的结果以及批准的方式通知渠道。
- 最终，一旦部署完成，机器人将在通道上显示最终消息。
功能/错误修正/更改生效后，应在另一个渠道（称为#changelog）上通知团队的其余成员，这是我将解释的第一个公共渠道。
公开频道
#changelog（公开）
在这个频道中，每个人都可以看到我们拥有的每个系统中已经部署了什么。 您还记得我在#deploys频道中提到的漫游器吗？ 这是第二个渠道，那里有一个机器人在做一些自动化。
以前，部署的所有者负责使用以下模板在此宣布已完成的操作。 除一个字段外，所有字段均与请求批准时在#deploys频道中使用的字段相同（带有星号的字段）：
- （ 什么 ）*
- （ 哪里 ）*
- （ 为什么 ）*
- （ 任务 ）*
- （ 测试 ）：（可选）如果可以从外部看到/测试（例如一项新功能），则可以执行一些步骤来确认已完成。
如您所见，其中涉及大量复制/粘贴，因此我们的slackbot得到了很大的改进。 当宣布部署完成时，机器人将自动更新更改日志通道：
＃
为了与所有利益相关者一起讨论某个项目的问题，公司中的每个大项目都有一个公共渠道。 在这里，不同团队之间可以协调行动，并且可以共享重要通知。
#madrid_office
最后，对于所有与办公室有关的问题或本地问题，每个办公室都有一个渠道。 就我而言，这是马德里的办公室。 在该频道中，您可以看到各种各样的信息，从一起订购午餐或询问确切时间在办公室的人，到下班后建议喝酒。
综上所述，我们使用以下渠道：
- #dev ：开发团队的协调和技术讨论。
- #dev_announces ：重要的更改，团队惯例和流程决策。
- #daily_learning ：文章共享和日常会议协调
- #vacations ：休假协议和团队协作
- #alerts ：与PagerDuty集成并通知关键问题
- #alert_discussion ：有关#alerts中发生的事件的讨论
- #deploys ：部署批准和协调过程
- #changelog ：部署通知和日志
- 项目特定渠道 ：与所有利益相关者讨论和协调单个项目
- #madrid_office ：与办公室有关的问题或本地问题
我没有提到其他一些渠道，但是我认为我从工程角度介绍了最有趣的渠道。 此外，这足以让您了解我们如何喜欢使用专用渠道。 最后，您可能还注意到某些渠道比其他渠道更重要，这是团队中每个人都必须意识到的。
如果您对我们如何使用Slack有任何意见或疑问， 请告诉我们 ！ 我们很高兴与Slack讨论技巧和最佳实践，也许我们可以改善使用它的方式。
