谈谈运维的价值
从软件生命周期的角度看，软件开发阶段只占整个生命周期的 20%~30% 左右，软件运行维护阶段是最长尾的。
开发和运维的分界点从开发完成代码开发，测试验收通过后，交付到运维软件包开始，之后的阶段就是软件的运行维护阶段了。
从运维的范畴上来讲，我认为，一个研发团队内，除去业务需求实现层面的事情，其它都是运维的范畴，这个范畴内的事情本质上都是在为软件生命周期中的运行维护阶段服务。
运维能力是整体技术架构能力的体现，运维层面爆发的问题或故障，一定是整体技术架构中存在问题，割裂两者，单纯地看技术架构或运维都是毫无意义的。
我们在绝大多数情况下，忽略了这个隐藏在软件生命周期中真正的运维范畴，而是简单直接地从软件生命周期分段的角度，生硬地给开发和运维划定了一条界限。
将运维仅仅局限在了服务器维护、网络设备配置、软件安装维护这些最末端的职责上。而我们又期望运维这个角色能够掌控全局，不要在这个阶段出现任何问题。这就很像临渴而掘井，是不现实的。
运维思路上的转变，远比单纯提升运维技术更有价值，而运维真正的价值应该跟研发团队保持一致，真正聚焦到效率、稳定和成本上来。
而这也正是我们很多公司和团队，当前所遇到的最大的痛点和问题。
分布式软件架构下的应用运维这个领域
主要有以下四个部分
应用运维体系建设
效率和稳定性等方面的最佳实践
云计算方面的思考和实践
个人成长与趋势热点分析
总结
1.从运维的范畴上来讲，我认为，一个研发团队内，除去业务需求实现层面的事情，其它都是运维的范畴
2.运维能力是整体技术架构能力的体现，运维层面爆发的问题或故障，一定是整体技术架构中存在问题，割裂两者，单纯地看技术架构或运维都是毫无意义的。
3.忽略了这个隐藏在软件生命周期中真正的运维范畴，而是简单直接地从软件生命周期分段的角度，生硬地给开发和运维划定了一条界限。
4.运维思路上的转变，远比单纯提升运维技术更有价值，而运维真正的价值应该跟研发团队保持一致，真正聚焦到效率、稳定和成本上来。