运维的二个核心点：保障业务系统稳定、高效、持续运行；降低运维中心的成本（运维中心是成本中心，而不是价值中心，是许多企业高层的共识）

服务目录包括：服务目录、服务详情两大部分

服务设计：供应商管理、服务目录管理、信息安全管理、IT服务持续性管理、容量管理、可用性管理、服务级别管理（SLA）服务转换：知识管理、评估、服务检验与测试、转换规划与支持、发布与部署管理、服务资产与配置管理(CMDB)、变更管理。服务运营：IT运营管理、应用管理、技术管理、请求实现、事件管理、访问管理、问题管理、事故管理、服务台。3) IT服务管理：事件管理、问题管理、变更管理、SLA管理、资产管

运维的标准化和流程化首先要以文档的形式进行展示，并且能够指导日常运维工作。国有国法，家有家规，冰箱洗衣机都有说明书，运维标准化流程化就是运维工作的国法家规，运维工作如何进行的说明书。相比开发、测试等其他岗位，运维工作直面生产环境，每一步运维操作与生产系统能否正常运行息息相关，稍有不慎就易产生生产事故。并且运维自动化的落地实施也是要基于运维的标准化和流程化，所以作为运维管理的第一步，不可忽略。

，随着事件管理流程、变更管理流程、服务请求流程的逐步梳理，开始有了各种分类的梳理，用户就感觉比较疑惑，怎么有这么的分类，他们之间的关系是什么？是否可以复用和参考呢？其实这个问题不仅是用户疑惑，很多刚接触ITIL4咨询的顾问也很有疑惑？什么时候梳理服务目录？目的是什么？事件分类的作用是什么，与服务目录的关系是什么？请求目录、变更分类设计的目的是什么？本文先着手分析服务请求与变更请求的区别与关系

chljapan1 人赞同了该文章我们在前一章，对元建模的基本概念做了一个简单的介绍，当然大部分还是基于互联网的解释。接下来我们进一步来理解元模型。我们先说一下目前模型驱动架构的现状。目前大部分的模型驱动架构，建立在领域驱动建模的基础之上，优点就不说了，我们只说缺点，那就是当我们的领域模型改变的时候，其他相关的模型层，都需要跟着改变，比如说持久层，业务流层，Bean层等等。当你的业务足够复杂，运维

数据集成离线/实时数据同步复杂网络环境下，对丰富异构类型数据源高效稳定的移动和同步能力数据开发对MaxCompute中的数据进行加工 (SQL，UTF，Graph，MR)、分析与发掘（数据分析、数据挖掘）等处理从而发现其价值数据应用对MaxCompute数据加工处理后，应用各种场景，如数据提取、数据交互、数据报表、数据分析数据服务提供为企业搭建统一的数据服务总线，帮助企业统一管理对内外的API服务

业务架构的主要内容，逐条分类进行梳理

技术架构主要包括两大部分：软件-技术平台/组件、硬件-基础设施，主要是对应用和数据提供哪些可用资源

数据系统架构设计原则：纵向细化数据总体架构内容，横向横向遵从对业务模型的原创依赖关系