关注留言点赞，带你了解最流行的软件开发知识与最新科技行业趋势。
SRE 是来自 Google 的术语本身。但本质上，它是 DevOps 投入部署的自动化，通过自动化管道来更快地部署变更。SRE 是关于自动化软件的操作方面。自动化软件的操作方面意味着作为 SRE，也许五年前，你只是调用 ITOps。现在，它被称为 SRE，即站点可靠性工程。
我认为 DevOps和SRE都已经发展到使用自动化和代码以智能方式和编码方式自动化某些事情。代码很重要，因为您可以控制代码的源代码。您可以保留所有管道的历史记录。SRE 也是如此。SRE 尝试通过代码将相同的东西自动化用于软件的操作方面。
因此，SRE 和 DevOps 可以很好地协同工作。我有一张 DevOps 和 SRE 牵手的幻灯片。他们手牵着手，因为最终，这一切都是关于通过自动化实现自动化交付。SRE 实际上更多地关注自动化 DevOps 中产生的东西的弹性。
这是一个“和”。左移实际上是关于更早地考虑所有这些约束，我们如何处理可观察性，并鼓励开发人员考虑他们需要什么类型的数据来确定系统是否健康。
跟踪、日志和更早开始测试是经典的左移。向右移动是关于了解我的系统的性能。这就像了解我的系统的心率——就像我的响应时间一样。在开发中，向右移动意味着我要确保负责运行我的软件的 SRE 团队，时移，这就是你运行它的方式，这是我希望从可观察性的角度看到的，这些是我的门槛. 如果这些都不满足，那么我希望您从性能、可用性和可靠性的角度执行这些操作。
我认为我们一直存在经典的 Dev 和 Ops 鸿沟。开发将构建一些东西并将其扔过墙。然后运维人员必须弄清楚如何正确运行它、如何扩展它以及如何进行容量控制。
现在，我们说我们需要更早地审视所有这些方面。我们需要预先弄清楚我们如何在开发中实现可观察性，而不仅仅是在运营中。这就是为什么我们定义可观察性，以对其进行测试。
我们正在获取所有这些成分并确定我们将要观察的内容。让我们在生产中也观察一下。我们知道门槛是什么。我们知道是什么让我们的系统健康。让我们确保我们也在生产中验证这一点。我们知道如果测试失败了，我们该怎么做才能使系统恢复到理想状态。让我们在生产中也将其编码，以自动方式恢复系统。这就是我对右移的定义。
