认识达内从这里开始

随着互联网的不断发展，越来越多的人都开始学习软件编程开发的相关技术知识，而运维管理就是其中的一个热门求职岗位，今天我们就通过案例分析来了解一下，运维管理在整个项目中的作用。

1、技术产品

整个运维过程中，运维一定要转变被动响应式的工作方式，要主动求变，其中重要的就是树立起产品意识，将日常的人肉的、繁琐重复的工作不断的总结和提炼。

比如，是不是能够把自己原本靠人工完成的很多工作转化成需求?是不是能够把日常工作中运维和开发的痛点转化成需求?是不是能够把当前系统存在的问题和隐患找出来，在解决的过程中，经过分析总结提炼成需求?

当需求提炼出来之后，是否能够准确的传递给工具开发团队，并跟工具开发团队一起把需求真正的落地实现?

以上过程，就是将运维的人肉能力转化为平台能力的过程，比如持续发布，没有发布系统之前，完全靠人肉堆，开发、测试和运维一起上，还经常出问题。但是有了发布系统，将人做的事情转交给平台自动化去做，终满足开发快速将代码发布上线的需求。

结合上面对产品的定义，看看我们上面做的事情，是不是就是一个技术产品的工作呢。当我们具备了这个意识，能有更多的工具做出来，逐步形成体系，我们的工作是不是变得更轻松了呢?

2、技术运营

运营的目的，和产品经理核心的不同是，要实现扩散，爆发，增长，收益等等。(摘自知乎)

通过上面的技术产品的工作，如果可以做出一些有针对的工具和平台来，但是仅仅有工具和平台就够了吗?不过，远远不够，为啥这样说呢?

a、推广落地，工具做出来了是一步，得要有人用，这就需要去推动落地。(跟业务上做出一个产品来，要去找渠道推广，要吸引流量过来，并终产生经济收益是一个道理。)当然，我们在内部倒不必吸引用户来用，因为我们的技术产品更多地是标准、流程和规范的载体，既然大家之前都遵守了这套标准体系，那就必须使用(使用之前做些小范围的试用还是必须的)，所以这个过程是可以强势一点的。比如线上仅保留发布系统一个变更入口，其他变更权限全部收回等等。

b、线上运行数据分析，应用上线或者每次变更上线后，线上运行的情况咋样，容量有没有降、RT有没有上涨、监控有没有异常，业务量上是否有激增、用户体验有没有下降，用户和客服的反馈如何等等。以上这些维度和指标就需要一张张的数据报表呈现出来，通过数据分析来指导我们要做出哪些优化和调整。(想想看，业务运营是不是也非常关注业务数据报表的)

c、过程改进，工具更多的是一个执行角色，但是工具的使用是要配合大量的标准和流程一起来运作的，比如说持续交付，里面就会涉及持续集成，再往细里讲，代码分支应该如何合并，出现冲突后应该如何解决，自动化测试需要哪些用例，用例等级如何定义，测试验收的标准是什么，构建失败应该怎么处理，当团队成员无法达成一致的时候，应该如何决策等等;再比如，b中提到的遇到的种种上线后的情况，应该对应什么样的机制处理下去，这些都是技术运营过程中所面临的问题。一方面要先有对应的流程机制确认下来，大家共同遵守，另一方面，执行过程中，如果有导致效率下降或者有更好的措施的时候，这个时候就需要过程上的改进。

我们面临的业务场景再不断变化，技术趋势不断发展，就决定了技术运营过程一个持续改进的过程。

3、技术服务

我觉得两层含义，一个是一定要有服务的心态;另一个，提供解决方案，还是举个栗子：

比如，我们在线上运维过程中，发现有一块相对独立的业务，体量越来越大，随着用户的增多从一个非核心的业务变成了一个核心业务。但是，这个业务是用C++来做的，架构上是分层架构，每层都是通过配置IP的方式进行接口调用，还有跨层的调用，调用逻辑很不清晰。遇到的比较突出的问题就是效率和稳定性：

a、发布的时候，就没法做到服务发现，要一台台改配置将流量迁移走，然后手工执行发布脚本同步代码，然后再将配置改回来进行验证是否成功了，随着机器数量越来越大，开发就吃不消了，太麻烦;

b、出现故障，的手段就是回滚、重启、干瞪眼，类似降级、限流或开关的稳定性手段都没有;

c、线上容量也没法评估，发布个版本发现容量不够，就扩容，而不是真正去找一下性能下降的原因;

这个时候发现了问题，我跟团队一起去做的事情，找到对方的主要负责人和其主管(或者对方来找我们)，大家一起坐下来，针对现在的问题和痛点，看如何改进，比如发布效率低，那发布的过程步骤是什么，我们一起看看什么地方可以改进和提升，比如有写死IP的情况，那是否可以做到分配从代码中分离，或者考虑服务发现的方案(服务发现考虑过，但是实现成本比较高，现在做需求还做不完)，那是否可以利用现有的服务化框架，然后给中间件团队提需求尽快支持C++的分布式服务呢?嗯，这个可行，我们一起找!

稳定性有问题，我们现有的稳定性系统支持开关、降级、限流，近碰到的问题如果有降级措施的话，是可以将故障快速隔离的，然后介绍下现有稳定性的解决方案，评估了下，嗯，可以搞。

结果是，双方共同配合进行改造，将一个维护效率和稳定性不高的业务大大改进了。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。