前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >自动化运维体系如何入手

自动化运维体系如何入手

原创
作者头像
iginkgo18
发布2023-07-21 14:11:22
4430
发布2023-07-21 14:11:22
举报
文章被收录于专栏:devops_k8sdevops_k8s

1 需求

运维是事件驱动,还是自驱动可能是我们在运维工作中不太关注的问题。事件驱动让运维止步于故障,而自驱动让运维不止于建设。持续性的运维建设就需要一套自动化的运维体系,那么我们应该从何入手?

其实前期《运维思考》一系列文章已经给我们答案了,就是从运维框架入手分层建设、打好基础,记住“万丈高楼平地起,勿在浮沙筑高台”。

2 运维框架

通常讲到运维建设,我们脑海中首先浮现的是“一团麻”,因为这不是一个人、一个岗位的工作,而是一整个团队的工作;所以我们将“这团麻”进行由底层向上可划分为:

IT基础设施层

IT基础设施层,主要由基础运维团队负责,主要包括存储、网络、服务器、安全设备等硬件设施;

数据层

数据层,主要由DBA团队、大数据团队负责,主要包括数据库、缓存、数仓等;

应用层

应用层,主要由应用运维团队负责,主要包括基础服务、业务应用、中间件等;

管理层

管理层,主要由配置管理团队、安全团队、应用运维团队负责,主要包括各种自动化操作、安全管理、监控管理等;

展示层

展示层,主要由各团队综合管理,主要包括各种管理工具、监控工具等;

通过对运维框架的分解,对各种资源的逻辑隔离,让各个团队明确当前运维建设中的现状与不足。 如果我们能做到对运维框架的持续性关注,通过图片就可以明晰的知道哪个团队的不足,以及日后各团队的重点发力方向。

3 运维依据

如果你觉得运维框架还不够细致,那么针对框架中各个层次的工作拆解就来了,我们在此将其称之为运维依据。

针对这些个运维依据,我们可以展开一些列的针对性措施,如制定规范、自动化流程,如此就能够不断丰富各个团队的制度、规范、流程,何乐而不为?

3.1 基础设施层

在基础的硬件设施管理之上,比较重点的工作是:

  • 网络分区与隔离

网络分区应考虑互联网接入区、普通生产区、数据区、外联区等各个区域,保证各区域的合理接入。

网络隔离对测试、准生产、生产环境各环境进行隔离,避免访问权限混乱。

  • CMDB资产纳管

CMDB用于管理基础设施层的各项资产,为上层应用提供数据支撑。使用CMDB一定要和业务应用紧密结合,一旦脱离于业务使用,那么CMDB将成为花瓶。

  • 内部dns

通过内部dns可以将应用与IP解耦,一旦ip变更则不需要变更代码,生产环境应该尽量少做此种类型变更操作。

  • 服务器快速上架

为满足业务日益增长的需求,应该具备服务器快速上架、资产实时记录至CMDB等一系列自动化流程。

  • 网络权限变更

根据应用需求,快速登记并开通网络权限。

等等

3.2 数据库

数据库除了特有的集群外,可以考虑数据库工单、sql审核优化等流程。

3.3 系统应用

  • 容量规划

容量规划是指根据业务用户流量增长、现有容量等一定的基础数据之上进行周期性的评估,如果有条件的话可结合压测实际情况,这样数据会更准确。通过容量规划可有效控制服务器规范,避免资源溢出。

  • 环境维护与部署

为避免因环境差异导致的问题,各环境应用部署需要遵循统一的目录规范,统一的自动化部署方式,分离的应用配置文件。

等等

3.4 配置管理

  • 统一账号管理

所有和用户登录相关的平台、管理工具,尽量接入ldap统一账号管理,这样一个账号可以实现所有系统的统一登录。

  • 自动化配置中心

在此秉承基础设施即代码的思想,通过ansible作为配置中心,在操作系统层面实现系统初始化、环境初始化、组件初始化、自动化备份等中心化管理,各环境交付统一规格的服务器。

  • 流程管理

结合jira等工作流工具实现操作的流程化管理。

等等

3.5 CI/CD

基于统一的运维规范前提下,CI/CD可以真正的做到将以上各个层面的想法、解决方案进行落地。因此CI/CD能力很大程度上决定了我们自动化运维的高度。

  • 持续集成

代码质量测试、单元测试、打包测试、自动化测试等。

  • 操作系统交付

遵循统一的运维规范,交付统一规格的操作系统,完成对运维平台各个管理节点的资源注册。

  • 版本发布

支持版本平滑发布、回滚、重启等。

  • 自动打包

Android/IOS 自动打包并上传至应用商店。

3.6 监控系统

  • 系统建设

多维度收集、分析监控数据,实现不同层面的告警;对于多维度的数据能够进行分析,实现故障自愈;

  • 监控管理

监控并不是只要做到告警进行了,而是要做到告警的准确性,因此对告警级别、告警收敛、故障自愈策略等的管理需要我们进行重点关注。

3.7 安全防护

通过必要的WAF、IDS、防火墙等安全设备进行安全防护、流量分析外,还要结合安全渗透去主动发现问题。

3.8 数据分析

通过对应用数据、业务数据、运营数据进行集中分析、展示,帮助我们更好的了解系统运行状况。

4 小结

通过以上各个层面的运维框架和运维依据,希望大家能够结合实际情况进行头脑风暴,做到不止于此。

当然自动化运维建设不是一蹴而就的,需要结合规范、制度、流程去逐步实现。

记住运维建设是过程,不仅仅是目标,我们需要跟随技术潮流趋势,持续的优化与丰富这个过程。

原创: 三页 木纳大叔爱运维

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1 需求
  • 2 运维框架
  • 3 运维依据
    • 3.1 基础设施层
      • 3.2 数据库
        • 3.3 系统应用
          • 3.4 配置管理
            • 3.5 CI/CD
              • 3.6 监控系统
                • 3.7 安全防护
                  • 3.8 数据分析
                  • 4 小结
                  相关产品与服务
                  微服务引擎 TSE
                  微服务引擎(Tencent Cloud Service Engine)提供开箱即用的云上全场景微服务解决方案。支持开源增强的云原生注册配置中心(Zookeeper、Nacos 和 Apollo),北极星网格(腾讯自研并开源的 PolarisMesh)、云原生 API 网关(Kong)以及微服务应用托管的弹性微服务平台。微服务引擎完全兼容开源版本的使用方式,在功能、可用性和可运维性等多个方面进行增强。
                  领券
                  问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档