网站建设天地心,网站代备案系统,杭州网站制作培训,网络服务器下载标准化的过程实际上就是对运维对象的识别和建模过程。形成统一的对象模型后#xff0c;各方在统一的认识下展开有效协作#xff0c;然后针对不同的运维对象#xff0c;再抽取出它们所对应的运维场景#xff0c;接下来才是运维场景的自动化实现。
在标准化的过程中#xf…标准化的过程实际上就是对运维对象的识别和建模过程。形成统一的对象模型后各方在统一的认识下展开有效协作然后针对不同的运维对象再抽取出它们所对应的运维场景接下来才是运维场景的自动化实现。
在标准化的过程中先识别出各个运维对象然后我们日常做的所有运维工作都应该是针对这些对象的运维。如果运维操作脱离了对象那就没有任何意义。同样没有理清楚对象运维自然不得章法。
比如我们说扩容那就要先确定这里到底是服务器的扩容还是应用的扩容还是其它对象的扩容。你会发现对象不同扩容这个场景所实施的动作是完全不一样的。
如果把服务器的扩容套用到应用的扩容上去必然会导致流程错乱。同时对于对象理解上的不一致也会徒增无谓的沟通成本造成效率低下。自然地这种情况下的运维自动化不但不能提升效率还会越自动越混乱。
标准化的套路
第一步识别对象第二步识别对象属性第三步识别对象关系第四步识别对象场景。
基础设施层面的标准化
基础设施层面的运维对象应该不难识别因为都是一个个物理存在的实体我们可以进行如下分析。
第一步识别实体对象主要有服务器、网络、IDC、机柜、存储、配件等。第二步识别对象的属性比如服务器就会有 SN 序列号、IP 地址、厂商、硬件配置如 CPU、内存、硬盘、网卡、PCIE、BIOS、维保信息等网络设备如交换机也会有厂商、型号、带宽等信息。第三步识别对象之间的关联关系比如服务器所在的机柜虚拟机所在的宿主机、机柜所在 IDC 等简单关系复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系等这些相对复杂一些也就是我们常说的网络拓扑关系。第四步还是以服务器为例我们针对服务器的日常操作有采购、入库、安装、配置、上线、下线、维修等等。另外可能还会有可视化和查询的场景如拓扑关系的可视化和动态展示交换机与服务器之间的级联关系、状态正常 or 故障的展示等这样可以很直观地关注到资源节点的状态。
完成了这些工作接下来才是对上述运维场景的自动化开发。
应用层面的标准化
第一步识别对象。这个识别过程是在做微服务架构设计或拆分的时候就确定下来的。所以严格地讲它不应该是运维阶段才被识别出来的而是在之前设计阶段就被识别和确认下来然后延伸到运维这里才对。
第二步识别对象属性。一个应用是业务的抽象逻辑所以会有业务和运维两个维度的属性。业务属性在业务架构时确定这主要是需要业务架构师去识别的但是它的运维属性就应该由运维来识别了。
一个应用应该具备哪些基本的运维属性。
应用的元数据属性也就是简单直接地描述一个应用的信息如应用名、应用 Owner、所属业务、是否核心链路应用以及应用功能说明等这里的关键是应用名*应用代码属性主要是编程语言及版本决定了后续的构建方式GitLab 地址应用部署模式涉及到基础软件包如语言包 Java、C、Go 等容器如 Tomcat、JBoss 等应用目录信息如运维脚本目录、日志目录、应用包目录、临时目录等应用运行脚本如启停脚本、健康监测脚本应用运行时的参数配置如运行端口、Java 的 JVM 参数 GC 方式、新生代、老生代、永生代的堆内存大小配置等。
第三步识别对象关系。也就是应用与外部的关系概括起来有三大类
应用与基础设施的关系包括应用与资源、应用与 VIP、应用与 DNS 等等的关系平行层面的应用与应用之间的关系这里再细分下去就是应用服务或 API 与其它应用服务和 API 的依赖关系。如果你有相关的经验应该会联想到全链路这样的工具平台了没错这样的平台就是用来处理应用间关系管理的。应用与各类基础组件之间的关系比如应用与缓存应用与消息、应用与 DB 等等之间的关系。
第四步识别应用的运维场景。
这个就会比较多了比如应用创建、持续集成、持续发布、扩容、缩容、监控等再复杂点的比如容量评估、压测、限流降级等。 此文章为2月Day20 学习笔记内容来源于极客时间《赵成的运维体系管理课》推荐该课程。
