在对讲机，我们的任务是使网络和移动商务个性化。错误页面、超时和响应缓慢与此相反。但在这种情况下，当事情确实中断时，正确地进行面向客户的沟通是非常重要的。服务中断会让客户感到沮丧，并阻止他们快速完成他们要做的重要工作。在我们这方面，停机对相关的工程团队来说压力很大，因为他们必须切换上下文，并争先恐后地修复任何损坏的问题。停机对每个人来说都是个坏消息，人工智能网络，但事实是，除了琐碎的服务之外，它们是不可避免的。为了确保将停机时间控制在最低限度，在对讲机公司，我们正在建立一种工程文化，在这种文化中，性能和可用性与快速和迭代式发货同等重要。这意味着我们要做一些事情，比如系统地从错误中学习，进行无过失的事后检查，设计出预期、包含并迅速从失败中恢复的系统。清晰沟通的重要性处理服务中断是一项艰巨的工作，但是很好地沟通服务中断期间发生的事情是非常困难的。面向外部的状态更新通常对恢复服务的优先级较低，而且很难正确进行更新并没有帮助。措辞拙劣的声明、使用虚假的词语或不及时的更新会削弱客户的信任。一些客户可能不喜欢技术术语，而另一些客户则希望知道确切的细节。指责第三方服务提供商几乎可以肯定是短视的。停机后，许多在线讨论往往集中在云和SaaS服务如何与客户沟通上，这表明客户有多关心他们被告知发生了什么。客户需要的信息当您的站点或服务关闭时，客户正在查找以下信息：有什么东西坏了吗（还是只有我一个人）？有人在做吗？什么时候修好？为了帮助回答这些问题，我们最近为对讲机设置了一个状态页（上图），使用状态页.io. 我们使用newrelic的应用程序性能指标和Pingdom的正常运行时间监控来实时地向我们的客户提供这些信息。你将能够快速发现是否有任何东西打破了对讲机现在和过去（长达一个月）。此外，成都大数据，我们将使用对讲机状态页提供事件发生时的更新。对讲机状态页面的更新也会同步到我们的@intercostatus Twitter帐户，所以如果你想在你的订阅源中看到通知，财务大数据，请关注它。目前在状态页面上出现的指标必然很简单。它们不会出现影响一小部分客户的问题，也不会影响对讲机的每个功能，只提供平均响应时间和正常运行时间。我们打算添加更多的指标，比如消息传递成功率，所以请关注这个空间，大数据学什么，当然，如果您希望看到什么，请告诉我们。提高对讲机的可用性在我今年早些时候加入Intercom不久，我们就发生了一系列与MySQL主数据库相关的宕机事件。对讲机在很大程度上是一个经典的两层rubyonrails web应用程序，而MySQL数据库是应用程序某些部分的单点故障。我们的体系结构正朝着面向服务的方向发展，但我们需要快速改进。我们对设置进行了一些更改，以更快地从中断中恢复，并通过调整超时、池大小和构建专用车队来服务不同来源的流量来控制停机的爆炸半径。我们还在构建新服务方面取得了一些重大进展，以降低存储客户数据的数据存储的复杂性（同时还改进了响应时间和客户体验）。我们的可用性指标已经改进，但我们仍在继续努力，在多个方面进一步改进我们的设置。我们想和我们的客户分享我们一直在做的事情，以及一些关于幕后所发生的事情的细节来改善事情。以下是2014年第三季度我们所做的一些数据，以及我们在幕后所做的一些影响性能和可用性的架构更改（基本上是积极的）。2014年第三季度的主要架构说明：升级数据存储容量–将NoSQL文档存储群翻倍，将RDS MySQL实例升级为最大的产品。在8月份对Ruby垃圾收集进行了优化，以提高吞吐量和性能。（如果使用rubymri2.0运行默认的Ruby垃圾收集设置，那么这样做很可能会让您受益匪浅！）。取消了nginx/passenger层的排队，以优化更快的恢复。优化进程/线程/数据库连接以优化以加快恢复。将Javascript API应用于专用舰队。Elasticsearch的流式用户更新在9月份增加了延迟。我们在2014年第四季度的目标是，每月的可用性始终高于99.9%。我们渴望得到有关我们的新状态页面、公开报告的指标以及我们如何就停机进行沟通的反馈。告诉我们是否有我们可以做的不同的事情，或者有什么你想看到我们开始做的事情。

，淘客链接