传统的运维体系中， 运维工具是不可或缺的一环， 各种部署、批量执行的任务需要完成， 为了脱离装机工的角色，运维工程师定制了大量的脚本工具供日常使用，但是随着运维成熟度提升，工具自身的操作成本开始凸显，在工具化之上，运维也需要向产品化演进，那么工具、 产品的区别是什么那？运维应该如何升级？处在技术链条的最末端，食物链的最低端的运维，价值应该如何体现？
工具和产品
工欲善其事必先利其器， 就像开始学会利用和制造工具是人类文明的开始，运维工程师从洪荒时代的装机工，演进到自动化运维工程师就是一个制造和利用工具的过程，利用工具一个运维工程师可以批量管理成千上万的设备，可以短时间内完成海量的部署任务。但是发展没有尽头，当业务规模越来越庞大，越来越复杂，运维工具本身成为了瓶颈，难以维护，没有统一标准， 使用成本过高， 不是自己写的工具有学习成本，碎片化严重等问题开始凸显，运维已经进入精细化管理的时代，运维产品化的必要性日益激增，工具化的特征是工具是给专业的人用的，运维写了一个工具， 很多时候只有运维工程师会用，甚至只有自己会用。而产品是给用户用的，这两者一个的受众用户是只能运维工程师甚至只能是自己， 另一个是用户， 受众面积，区别不言而喻， 而产品化的目的，就是尽可能的降低产品的使用难度，降低使用的心智负担。
运维开发的产品化挑战
产品化优势
运维总是需要不断的学习和充实自己，运维人对技术抱有天生的敏感和热忱，在产品化的过程中， 一个很大的优势是运维是由场景强驱动的，具备极大的丰富性，来个需求可能就是个场景要去适应，所以运维总是在踩不一样的坑背不一样的锅，CI/CD、 kubernetes、 service mesh、serverless、操作系统、网络、中间件更不用说五花八门的业务和基础设施，而产品化需求，本就是需要需要参考不同运维角色、不同规模、不同业务等各种因素去综合考虑。运维这个职业天生具备这样的特质。
产品化劣势
运维从工具化到产品化必须经历的考验是：如何提供符合场景， 具备良好使用体验的运维产品。产品是什么：基于产品经理意志转化输出的结果， 可见个人色彩很浓厚，而人的思维千差万别，没有产品思维打造出来的产品可想而知。也因此，产品化自然对产品能力要求较高。运维产品化的难题中， 我觉得最难的，就是工具思维到产品思维的转变，而现实是普遍的，运维的产品能力普遍薄弱：用纯运维的思维去做产品，是很多运维平台建设失败的原因：
何不食肉糜：为啥不敲几行命令来解决，有必要加个功能吗？
不面向用户：反正我们自己用自己能明白就行，实际上其他运维也不一定明白的了。
不面对核心需求的炫技：这个技术挺牛X的， 我们做这个吧，忽略真实痛点和需求，追求高大上。
如何具备产品思维
运维开发产品思维的本质: 从运维实际、核心的需求点及痛点为出发点，结合自身场景及其他多元场景情况，制定产品。技术只是手段， 业务才是王道， 运维不光是需要技术上的不断改进与创新，更需要思维观念的改变，学会站在产品的角度思考问题。
产品思维养成:
自我辩证: 不断尝试多几个角度来推翻自己之前的想法。直至难以动摇。
群众的呼声：对一个产品经理来说闭门造车是大忌，设想了一个运维产品，一定要不断的与用户(运维)对称，聆听不同角度的声音和质疑。接受吐槽、认真思考，集思广益至关重要。
不断打磨: 好的产品不是设计出来的， 是打磨出来的。不断的推敲， 收集用户体验信息， 持续优化，趋于完美也很重要。
运维产品化的价值
可以很大程度上为运维&研发提效。降低运维操作的门槛，让运维从理性的日常工作中尽可能的得到解放。让研发可以自助完成日常需要运维参与协助的工作。
好的产品可以创造收益让运维不再只是消耗成本的一方。
技术一定要服务于业务，否则就毫无价值，上面提到运维处于技术链条的最末端， 所以运维背锅，运维兜底，运维不能被业务推动着走，而是应该用产品化的思维，具备前瞻性的始终走在业务之前，作业务坚实的后盾。这就实现了运维价值的最大化。
