IT运维，一个专职"背锅"的岗位行业。面相多终端信息技术，多技术媒体渠道，最终面向终端用户。不管环境如何，技术栈简单与否，情境总是大体相同。
运维人大体都会谈论共同性工作特点：（1）机构组织的不重视（2）工作频类与琐碎（3）面向用户的责任（4）内部化解矛盾沟通的坪效低。槽吭满满，听到做运维的人，大体都会聊过以上，每家公司必有。
见到过很多人说"运维岗位不ok"，转型开发。更有甚者很多优秀it应届生对运维岗位避之不及。
简单来说"大运维"，分运维和交付两块业务，互为前置的因果业务关系连接线。信息技术发展到今天各种行业应用与需求爆棚式发展，行业场景需求差异，技术栈应用差异。决定"大运维"的工作难度挑战性，与灵活性。
大运维中，交付看的是用户需求满足，技术实现，成本把控三个策略，最终以可预期结果为导向，性质包含项目。不单单是项目型的标准契约输出，交付考虑环节流程的元性。项目设定的目标结果实现不一定是满足环境的，交付面相用户与环境本身，往往要突破最忧。
最实质的例证：交付决定，甲方付不付最后的40%。很多项目尾款流产，当然，除去不合法因素除外，大多数是交付没有最忧化。换句话说最优化交付结果很难。
运维很难，唯恐避之。时间干久了，思维化中心往往进去了盲目的技术栈优化，业务关键的逻辑性。这是完成运维人走不出去的惯性思维。坑总是要填的，用户服务是第一位的，用户个性是变化的。等等。想想哪个好处理？交织与捆绑式的作业陷阱。
大运维是一个长期存在且持续的活动。交付包含项目，运维是运营的缩版。一个全集，一个子集。大运维，"大范围"，想做好很难。
与之负面，运维是出人才得地方，行业产品架构师多运维出身，懂技术，了解用户，在学学产品设计，业务逻辑导出。把控沟通纽带。基本胜任"产品经理+架构师岗位"。
干运维，不单纯的去看运维。看价值，运维是一个长期被低估的价值链。（1）长期的作业成本消耗（2）不直接参与IT研发生产（3）长期维保"稳定状态"。
中国式IT，通用企业现状，人员复用超饱和。因不直接作用it研发生产，不带来直接产能输出。现有环境长期处于"低配高用"的状态。
不单单说运维，所有IT链条平行岗位，都有各自的弊病，干好不容易。毕竟，IT一个思维与技术高速运转主导的行业。
当今被高估的开发作用价值论调是不对的。任何技术起点很简单，一旦涉及工程，多简单技术应用的集合就是一个庞大的模型与系统技术实践路径规划图。
复杂并不可怕，多向性打包与拆包的过程。说起来简单，合理重组，优化，分配，调整，很难。经常会用到"戴明环"理论，进行周期性的PDCA改善滚动。
环境的多元复杂决定，规模群系的大小。都是影响着眼点的关键。
时间和岁月总会磨平很多东西。运维是一场人与环境，人与机器，人与人的多维修练场。
