自商业互联网最早以来，Microsoft一直在运营复杂的在线平台。 在此过程中，我们制定了一套实质性的做法，使系统保持可用、健康和安全。 这些做法是维护和改进 实时网站文化的更大举措的一部分。
实时网站文化
实时网站文化是组织关注的焦点，可优先处理实时网站的体验和可靠性。 毕竟，客户现在可以通过云和基于 Internet 的服务轻松跨服务提供商移动，极大地放大了客户信任的重要性。 实时网站必须始终可用，并按承诺对客户执行。
有各种因素有助于成功的现场网站文化。
首先实时网站
将实时网站体验放在第一位是成功平台不可或缺的一部分。 Teams 不能将所有注意力都放在新的闪亮功能上，并忽略向用户展示这些功能的途径。 我们依赖于 安全部署做法 ，帮助确保我们的客户享受不间断的平台访问。 在 发布版本控制服务更新时，这可能会变得特别复杂，且不会停机。
通过功能标志控制曝光
当我们通过 层和阶段进行部署时，通过 功能标志控制曝光，我们偶尔会发现生产中 的问题 。 尽管我们的所有自动化和评论，但有时仍会发生事情。 正如他们所说， 没有像生产这样的地方！
通常，运行状况监视和遥测在内容不正确时提醒我们。 开发人员可以创建分支 main，进行修复，并将其拉取到 main其中。 保留相同的常规工作流意味着开发人员不必进行上下文切换，也不必了解不同的代码更改过程。
若要解决修补程序部署问题，需要执行一个步骤，即将更改切入发布分支。 我们每天上午从当前发布分支运行修补程序部署，不过我们也可以按需进行紧急修复。 修复程序实际上先从发布分支中命中生产。 但是，由于我们首先进行开发 main ，我们知道在从 main中创建新版本分支时，它不会回归下一个冲刺。
虽然没有部署层和阶段，但本地产品的发布大致相同。 此外，由于我们在不同的配置和数据形状上进行更多的手动测试，因此在削减发布分支并将产品放在客户手中之间有较长的尾部。
应亲自执行安全性
重点是使漏洞真实和个人化。 这可确保人们真正关心。 我们还利用 战争游戏 来查找和解决整个系统的安全风险，无论是在代码中还是不。 当红队可以通过倒置对话框来显示他们进入代码时，它确实会激励代码所有者解决问题，并确保它不会在其他地方再次发生。 这种竞争比关于潜在的 XSS 风险的静态分析警告更真实和个人。 我们通过战争游戏和其他安全演习创造这种文化和动态。 人们自豪地侵入对方的代码或能够阻止尝试。 这会灌输安全代码区域性。
我们不能为每个攻击途径进行规划，但我们可以做的是假设会有违规行为，并计划我们可以对该违规做出反应的速度。 对于我们的团队来说，很多安全工作都围绕这一点。
最后，人类犯了错误。 它们有时会延迟，并执行诸如在文件共享上存储密码之类的作。 我们可以告诉他们不要，我们可以把他们送到安全培训，我们可以做各种各样的其他事情。 大多数人学习，但只需要一个人来打破这个系统。 你可以拥有各种最佳做法列表，但除非你做到了，否则你必须假设人们会犯错误。 这需要一定程度的监督，以确保遵循关键流程。
工程不仅仅是运营合作伙伴
我们早就学会了现场，使现场成为工程团队职责的重要组成部分。 这对我们来说是巨大的，因为过去，一个人可以部署一些东西，离开周末，并返回周一找到900个客户问题，客户支持和运营团队正在处理所有周末。 工程为现场问题付出代价很重要。 否则，生成避免这些问题的系统没有动力。 当你在凌晨 2 点被叫来修复你崩溃的东西时， 你记得。
随着我们发展这一责任， 现场网站是我们做的最重要的事情 ，成为整个团队的口头禅。 这是他们现在拥有的客户体验，不仅仅是税收。 这实际上是人们从我们身上指望的东西，我们为此感到骄傲。 它必须是产品的不同功能。
生产遥测是服务的检测信号
为了在速度快的世界中生存，几乎任何事情都出了问题，我们需要强大的警报系统。 无法作的警报、冗余警报或压倒性的警报卷会使你忽略所有警报。 创建过多的警报很容易，因此该过程确实会减少到一个简单的问题： 此警报是否可作？ 这可确保我们参与正确的客户问题，并尽快处理这些问题。
由于工程团队对可作的警报进行零处理，他们注意到，出现很多问题，尤其是在深夜，往往有类似的修复，至少暂时。 这导致了对系统的关注，这些系统在故障转移和自我修复方面做得更好。 现在问题发生，发出警报，然后修复自己足够好，使工程团队等到早上才能修复。 如果工程团队刚刚推出一些位， 让其他人晚上上床， 这不会发生。 现在，他们努力平衡这些改进，这不仅是特征速度，而且是工程改进速度的一部分。
概要
采用实时网站文化影响了Microsoft生成和交付软件的方式。 通过使工程团队成为安全和运营的关键部分，我们的代码和最终用户体验的质量有了很大的提高。 作为运营的完全参与者，使工程成为一个关键利益干系人，从而生成了专为更好的运营而设计的系统。