2017-12-231.软件系统中，基础设施和组件都是为上层的一个个业务应用所服务的，识别和建立它们之间的关系的非常重要，这个是运维体系化的前提。
2.要从应用的视角去看这些基础服务，不要将它们与应用割裂。
3.应用运维层面管理混乱，运维无法场景化，流程无法闭环，首要看是不是忽略了应用这个核心。 21
2017-12-23传统的开发模式以产品发布上线为一个节点，但是在现在的敏捷开发和微服务体系下，线上运行也只是整个开发流程中的一个环节。不论是以业务为导向，还是以功能为导向的开发，都需要将开发运行维护的所有环节纳入完整的体系之中，这也便要求整个开发团队的管理者或架构师有全面的统筹规划的能力，以便促进各个模块之间的协调合作。
而国内开发者可能面临更多的问题就是架构体系受限于组织结构，管理者缺乏对结构转型的经验和能力，自然导致团队成员缺乏思维转变的动力。作者回复: “要求整个开发团队的管理者或架构师有全面的统筹规划的能力，以便促进各个模块之间的协调合作。
而国内开发者可能面临更多的问题就是架构体系受限于组织结构，管理者缺乏对结构转型的经验和能力，自然导致团队成员缺乏思维转变的动力。”
上面这段分析的非常到位，也是我一直在讲的现在做运维，首要是思路上要先转变过。后面有几篇文章中我也会提到类似的观点，还有一篇专门介绍组织架构和组织协作的，欢迎继续讨论！ 6
2018-03-09请教一下如何维护后续的应用与基础设施和组建的关联关系？比如研发更新版本在某个缓存里增加了一个namespace，或者消息队列里增加了一个topic（类似这种资源申请是代码里可以自动创建的，可能运维都不知道），以应用为中心的关联关系信息如何维护？人工录入维护还是任何资源申请后台申请还是怎么样？谢谢作者回复: 这个要进行约束的，比如创建接口必须要鉴权，不能随意调用，申请环节必须要走流程，也不能随意。我们要做的就是尽量让流程简化，自动化，提升效率。
2
2019-07-06每一次读都有新的体会。结合工作中的实际情况，会有新的感受和理解。跟接触到不同的开发团队也有莫大关系。 1
2018-02-28哈哈，每次看作者的文章都有一种从文章中验证自己想法的感觉，读着读着，就会感慨，原来作者也是这么想的，很感谢公司，一来是初创公司，有很好的窗口去做这件事，二来是领导的前瞻性和信任，最后这件事才得以顺利实施。PS:开发确实缺少运维思维，运维和开发两者的确需要互补，前提是开发能把端到端交付先完成，不然整个流程都没走完。作者回复: 事物发展的规律都是相同的，所以只要经历过，就会有共鸣。
可以多留言讨论。 1
2019-07-19还是个传统公司的运维，一直想要融入到新项目的筹备，可是只是最后上线才知道有这个项目，传统的方式作为一个运维好难改变现实
2019-05-16很不错，我们目前所在的公司就是使用了微服务但是不成体系，相互对立！
2019-02-17一切都应该以应用为基础，包含cmdb和变更管理等等
2018-06-28我更新到现在版本后，复制app里的文章粘贴出去，再也无法完整粘贴了。请帮忙看看。
比如，复制了一大段，粘贴成了这个样子：
我会从这几个方面来讲：应用的起源、应用模型和应用关系模型建模...
极客时间版权所有: https://time.geekbang.org/column/article/1682?device=geekTime.ios
2018-02-24“架构体系受限与组织结构”是国内互联网公司运维发展过程中的普遍问题，在这种情况下，是自上而下去推动转型还是自下而上去争取变革，两种情况下的实现难度有着巨大差异。转变思路，不仅仅是运维需要转变，还包括产品、开发、测试一起。对于背负历史包袱的项目和产品来说，运维模式转型是成本开销，希望可以听老师分享一些如何推动产品进行运维模式转型的实际案例，以及如何换位思考去影响和推动开发思路上的转变。作者回复: 后面的很多文章都是介绍技术产品实践案例的，你可以先看下后面的文章。
2017-12-24paas的能力，有助于微服务作者回复: Paas的本质是什么？