运维前移/左移系列（一）
大概在2014年，当时所在团队面临变更引起故障的难题，组织了一次运维前移的工作，比如由运维工程项目团队牵头建立项目可行性评审，应用运维团队参与到概要设计、详细设计（非功能性设计与重大功能改造）、集中变更评审、运行评估标准，与特定研发线沟通变更发布与交付涉及的数据库表、文档标准等等。部分工作思路可以参见当时的一篇文章《变更产品交付标准化》相关的工作与当前一些组织提到的运维左移有点类似。
运维左移（将运维前移与左移统称为左移）在当前复杂的变更风险、更快的交付速度，以及稳定性SRE的工作理念下，愈发突显其意义。运维左移的命题较大，很多组织会以外部政策、公司战略、生产故障等事件驱动为触手增强左移的范围与深度。也有不少企业的IT组织从IT的技术、产品、服务角度引领企业转型，提出了IT左移，相比IT左移，运维左移将根据运维自身禀赋，围绕运维的价值创造而建立。建立一个可扩展性的运维左移知识体系需要关注以下几点：
在目标上，左移要围绕运维价值创造：“提高业务连续性保障、提升业务交付速度、辅助提升客户体验、提升IT运营服务质量”。
在范围上，左移通常是从软件交付的时间线上向左移，并不是所有工作可以称为左移，比如：测试环节的压力测试、评审环节的架构韧性、概要设计中的可运维性涉及的数据与接口设计等。
在内容上，左移可以考虑从：“制度、标准、流程、人员、环境、工具”，其中制度是为了师出有名，标准（及规范、准入）是细化为可执行细项，流程是将机制保障线上落地，人员是将运维角色前移并推动运维角色的技能的提升，环境是运维核心领域的前置，工具是平台赋能。
在战术上，左移要结合“面临痛点与价值期望”+“事件驱动”两个切入点，更有利于左移的落地。
本篇对运维左移开个头，画个左移知识体系的分析框架，后续重点围绕左移主线不断完善范围项，计划下一篇为“运维左移系列（二）之压力测试”。
