自被微软收购以来，GitHub的跌幅是否更大？
两年前的2018年6月4日，微软宣布以75亿美元的股票收购开发者工具创业生态系统的独角兽宠儿GitHub。这份公告挖出了从“GitHub注定要倒闭”到“微软是聪明的”的各种观点和公告，很多人对GitHub的未来做出了预测。一些人认为，微软对其云服务Azure的投资不断增加，可能会对GitHub有所帮助。微软的一项投资能否提高GitHub的可靠性，或加强它们抵御DDoSes等宕机的能力？这些预测中有没有成真的呢？
我们开始分析收购GitHub的一个角度：自从被微软收购后，GitHub变得更加可靠了吗？我们的服务StatusGator监控着大大小小的云提供商和SaaS公司的700多个状态页面。我们对状态页面数据进行聚合和标准化，并在订户需要时将其提供给他们：通过电子邮件、松弛、团队或网络挂钩进行通知，以及在所有服务依赖项的统一状态仪表板中提供。
5年多来，我们一直在分析GitHub状态页面。StatusGator每隔5分钟截屏一次，收集其服务状态的相关数据。这意味着我们在分析GitHub自己通过其状态页面宣布的停机时间方面具有得天独厚的优势。
数据告诉我们什么？在宣布收购后的两年里，GitHub报告的状态页面事件增加了41%。此外，与宣布之前的两年相比，事件记录增加了97%。这是否真的意味着可靠性的下降？我们不能说。这可能仅仅意味着GitHub增加了透明度，更频繁地发布到他们的状态页面。
我们计算了在宣布之前的24个月和宣布后的24个月内的事件计数。我们将状态页分为四种状态：启动、警告、关闭和维护。GitHub不会在其状态页上显示计划维护。对于这些计算，我们将事件视为在启动和警告或关闭之间的任何状态更改。
在收购之前，GitHub状态页面上发布了89起事件。之后，一共发生了126起事件。增长41%：
在下面的图表中，我们按月绘制了事件计数图表。左侧显示之前的24个月，右侧显示之后的24个月：
我们通过减去事件的开始和结束时间来计算事件分钟数。虽然不是100%实时，但StatusGator检查频繁：每5分钟检查一次，因此可以快速检测到状态页更改。我们计算了页面未处于整体打开状态的时间。
在宣布收购之前的24个月内，停机时间为6110分钟。在之后的24个月中，停机时间为12,074分钟，增加了97%：
在下面的图表中，我们按月绘制了事件分钟图。左侧显示之前的24个月，右侧显示之后的24个月：
在这四年中，GitHub在其状态页面信息粒度和设计方面做出了巨大的改进。2018年12月，他们从一个自制的状态页面切换到了由Atlassian的StatusPage服务运营的页面，后者是最受欢迎的状态页面提供商。在这样做的过程中，他们添加了许多单独的组件状态。以下是GitHub切换到Atlassian StatusPage之前的状态页面：
当他们切换到新的状态页面格式时，GitHub通过详细说明以下单个服务组件，朝着提高问责性和透明度迈出了一大步：
随着时间的推移，他们已经扩展和完善了他们的组件状态。他们还开始在状态页面上直接显示历史数据。正如您在其最新和最详细的状态页格式中看到的那样，它显示了以下服务组件状态：
他们还将他们的状态页面移到了一个专用的域名githubstatus.com，这遵循了我们向任何托管状态页面的人推荐的最佳做法。所有这些额外的透明度、详细信息和历史数据都是传递有关所有GitHub系统状态的最新信息的值得称赞的努力。更多的关键云基础设施提供商应该效仿GitHub的做法。如果您不使用您的状态页，它将毫无用处。
我们可以从所有这些数据中得出什么结论呢？客观上，我们可以得出结论，GitHub在他们宣布收购后的两年里，在他们的状态页面上发布的频率更高了。他们发布了更多的中断和停机事件。这些事件的持续时间更长。根据他们提供的数据，自微软收购GitHub以来，GitHub的跌幅更大。
但这可能都是协同努力的一部分，以提高他们的服务状态的透明度，这一努力应该得到称赞。
我们在StatusGator的目标不是因为中断和停机而羞辱任何人。每个人都会经历意想不到的停机时间。我们只是努力以更有用的方式使状态页数据可用和可访问。从Slake和Microsoft团队，到WebHooks、API等等。StatusGator聚合状态页数据，使您能够随时通知您的团队。
您的团队是否依赖GitHub？考虑试用StatusGator，30天免费。您可以通过我们监控的状态页面获得有关GitHub和670多项其他服务的通知。您可以通过电子邮件、短信或网络挂钩在Microsoft Teams、Slake中接收通知。我们最喜欢的特性是与/statuscheck斜杠命令的Slake集成，该命令允许直接从您的团队所在的位置查询任何服务的状态。
试试StatusGator的30天免费试用版，让我们知道你的想法。
