大神教你如何构建面向应用的运维管理新思维_以应用为核心运维(2)

2401_84140060

于 2024-05-12 08:11:47 发布

阅读量669

点赞数 8

分类专栏：程序员文章标签：运维学习面试

本文链接：https://blog.csdn.net/2401_84140060/article/details/138742323

版权

程序员专栏收录该内容

144 篇文章 0 订阅

订阅专栏

最全的Linux教程，Linux从入门到精通

======================

linux从入门到精通(第2版)
Linux系统移植
Linux驱动开发入门与实战
LINUX 系统移植第2版
Linux开源网络全栈详解从DPDK到OpenFlow

华为18级工程师呕心沥血撰写3000页Linux学习笔记教程

第一份《Linux从入门到精通》466页

====================

内容简介

====

本书是获得了很多读者好评的Linux经典畅销书**《Linux从入门到精通》的第2版**。本书第1版出版后曾经多次印刷，并被51CTO读书频道评为“最受读者喜爱的原创IT技术图书奖”。本书第﹖版以最新的Ubuntu 12.04为版本，循序渐进地向读者介绍了Linux 的基础应用、系统管理、网络应用、娱乐和办公、程序开发、服务器配置、系统安全等。本书附带1张光盘，内容为本书配套多媒体教学视频。另外,本书还为读者提供了大量的Linux学习资料和Ubuntu安装镜像文件，供读者免费下载。

华为18级工程师呕心沥血撰写3000页Linux学习笔记教程

本书适合广大Linux初中级用户、开源软件爱好者和大专院校的学生阅读，同时也非常适合准备从事Linux平台开发的各类人员。

需要《Linux入门到精通》、《linux系统移植》、《Linux驱动开发入门实战》、《Linux开源网络全栈》电子书籍及教程的工程师朋友们劳烦您转发+评论

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

动作

应用的变更有很多种场景，按照角色来归类，比如说应用交付、应用升级等场景，这些场景是面向Dev/Test/Ops的。还有一种应用在日常维护过程中的变更，面向纯Ops场景的，比如说应用的迁移、应用的扩容。动作是作用于资源的，比如说应用升级是版本发生变化，应用扩容是让应用的资源新增等等。过去的传统式运维，总是聚焦碎片式的运维自动化能力理解上。

状态

为了实现对应用的健康状况或者质量的度量，我们需要采集各类状态数据，从而支撑各类场景的应用，比如说监控故障发现的需求，故障恢复的需要，应用服务优化的需要等等。

CMDB建设的不成功，部分是系统的原因，但更多是方法论的问题。我们总以为找到了很强的驱动力来建设资源维护的流程和场景，其实这些都是自己的设想。数据中心的基础设施部门统揽CMDB的一切配置建设和管理，资源部门，根本不关心且没法关心资源所关联的上层应用是什么。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

因此我主张把CMDB建设分层建设，业务层和资源层CMDB可以分开建设，但一定以应用的CMDB建设为主，倒推资源层的CMDB建设完善。以应用为中心的IT资源生命周期管理建立起来之后，资源的广度不断拓宽自动化的深度。

但一定要注意CMDB的信息分成两类，一类是实例信息，一类是连接信息，也称为拓扑信息。拓扑信息需要结合我们平时的工作思路来建设和维护，比如说架构视图，是研发转维的过程中，必须要提供的输入，就是应用架构文档。部署视图，是指这个应用上线部署在哪些机房，哪些node。基础架构拓扑是物理overlay，这个地方表达的是基础设施层面的关系。业务流视图分成应用服务和端到端服务构建的能力视图，类似访问流拓扑。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

从应用的角度，资源的信息都能够很好的维护起来。此时就考虑如何支撑应用的动作了。这个场景起来之后，真正能解决CMDB数据维护动力和价值问题。面向应用的视角，提供完整的应用自动化和运维自动化能力。应用自动化打通Dev/Test/Staging/Prod等环境，构建面向用户的端到端自动化能力。典型的场景就是交付流水线，示意图如下：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

可以把一个端到端的交付流水线，分成了四个标准化过程，纵向就分解了阶段、环境、动作和角色等概念。

阶段

是对交付阶段的逻辑划分，对于一个企业的某个产品来说，建设的标准是单一交付流水线，而不是多交付流水线，单一交付流水线才能保证整个交付过程的一致性。一般分成研发、测试、预发布和生产运维阶段。

环境

环境是以上四个阶段的进一步细分，在每一个阶段会存在多环境的问题，比如说测试阶段，有UAT环境、SIT环境;在生产阶段，有正式生产集群、有容灾备份集群等等。

动作

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

交付的能力是动作来实现的，这个动作是一连串的能力编排。这个动作可以分解成部署动作和附加动作。部署动作是完成一个环境部署的标准化过程，比如说初始化环境、安装程序包等等，附加动作是针对特定环境要完成的一些动作，比如说针对用户接受性测试，可能会运行自动化测试等等。部署动作要确保在各个环境之间的一致性，这是部署脚本的基本能力，避免动作行为异化导致结果不同。

在动作层，还可以面向封装大量的自动化流程、工具能力等，这些能力都是满足一切应用场景的个性化。

角色

谁来执行这些动作，不同的环境可以面向不同的角色，这是权限的控制。通常分成开发、测试和运维角色，但真正到企业内，角色的划分会细致的多;其次这个角色也是随着管理模式变化而变化的，测试人员可能来做生产环境的部署。

这个自动化能力就不是运维自动化，而是IT自动化。IT自动化的平台可以由运维来建设，确保可扩展、插件化的能力。扩展的能力，是能力可以延伸到不同角色的需要，插件化是可以集成不同角色过去的工具能力，从而实现一个面向DevOps的应用交付平台。

再回到运维自动化，在面向应用的自动化场景上，依然可以通过服务编排的模式来实现。但是回到其他运维资源上，就逐渐失去和应用的关联，从管理方便性的角度来说，更是如此了。举个例子，比如说数据库的维护，大家肯定都是喜欢对数据库的实例进行维护和变更，而不是再加一个应用的维度。在面向Iaas和PaaS能力的自动化上，可以面向资源进行动作服务编排，从而实现运维的自动化。

状态其实是面向应用的一种度量手段，度量越贴近应用，越贴近服务，度量的有效性就越强。监控手段是度量的一种，大家很多时候把监控的告警能力、发现问题作为核心手段。但从这个维度出发，告警泛滥成为必然，大家不断的去看提升告警的准确性，做告警收敛和告警关联。我们的做法是告警可视化分层面板，在时间这个维度上，把告警统一展示，面向应用层的告警权重增大，底层的告警权重变小，衡量应用的健康状况。其次在统一的看板上，人的思维会发生变化，底层的告警能力会不断形成决策参考数据，而非当成直接的问题，甚至可以告警一致。这都是因为以应用为中心，数据有了关联所致。

面向应用的运维管理新思维，是切实有效的，给过去的很多未解问题提供了解决方案，这也是我过去不断强调要“建立以应用运维+运维研发为核心的组织体系”的原因。应用的是贴近业务的，因此应用是驱动力最强的。

为了做好运维面试路上的助攻手，特整理了上百道 【运维技术栈面试题集锦】 ，让你面试不慌心不跳，高薪offer怀里抱！

这次整理的面试题，小到shell、MySQL，大到K8s等云原生技术栈，不仅适合运维新人入行面试需要，还适用于想提升进阶跳槽加薪的运维朋友。