技术运维平台选型思考2023
2023-02-22 11:49:36 2 举报AI智能生成
登录查看完整内容
针对传统型技术研发公司，在200人左右的团队规模，结合多年实践经验，从传统的运维模式以及面临的挑战进行剖析，提出DevOps自动化运维理念，通过技术解决运维痛点和效率，打造一应俱全的运维平台，降低交付难度，提升运维自动化、智能化，提高运维效率，提升业务连续性和安全性。
作者其他创作
大纲/内容
当开发人员完成编码，测试人员测试验收通过后，到了要发布的时候，就会将程序交给运维人员部署发布到生产环境
传统开发模式
超链接
分支主题
安装升级操作系统
安装更新应用软件
更新数据库、配置文件
日常的更新维护
程序的部署更新
保障线上服务的稳定运行
对服务器 24 小时监控，有意外情况发生时需要及时处理和解决
运维工作职责
服务器数量少，运维工作以手工为主，自动化为辅
早期
服务器数量越来越庞大，且业务都逐步往云上迁移
基于 Docker 虚拟化技术来搭建在线服务的基础架构
以前的手动方式或者半自动的方式难以支撑，需要更多的自动化和基于容器技术或者相关工具的二次开发
对于运维的工作来说，运 维人员也需要更多的开发能力
目前
1、服务器规模快速增长和虚拟化技术的高速发展
一般几天或几个月部署发布一次
每一次的部署发布， 也可能会导致系统的不稳定
频率不高
传统软件部署
每周甚至每天都会有若干次的更新部署
频率很高
开发想要快速更新部署
对运维来说，每次更新部署会导致系统不稳定，最好是不更新，维持稳定的状态
引起开发和运维之间的冲突
面临挑战
敏捷开发&持续交付
2、高频的部署发布
目前面临挑战
传统的运维模式以及面临的挑战
解决开发和运维之间的沟通协作问题，提升运维开发和自动化能力
核心价值
DevOps 可以理解为一种开发(Development)和运维(Operations)一起紧密协作的工作方式，从而可以更快更可靠的构建、测试和发布软件
怎么理解
不再抵触开发的频繁更新部署
会帮助搭建自动化部署平台，提供自动化部署工具
对运维
不再认为运维的工作和开发没关系
开发人员会邀请 运维人员参与架构设计，帮助运维实现自动化脚本开发
对开发
产生影响
通过自动化应用，打破开发和运维之间的壁垒方式
整个软件的构建、测试和发布过程高度自动化
不了解程序在服务器上运行的情况
对开发来说
程序就是个黑盒子，无法对程序内部进 行监控，出现问题只能重启或者回滚
对运维来说
信息不透明
传统模式
可以直观看到开发到部署需要多少时间，哪个环节可以改进?
当前服务运行情况如何，每分钟访问数多少，API 出错率多少?
当前用户数多少，有多少新增用户?
信息更加透明，通过日志和工具，数据也可以被更好测量
DevOps
帮助运维更好地预警
帮助开发更好地优化程序
帮助业 务团队更好地了解服务的运营情况
数据价值
信息更加透明和易于测量
不仅限于开发和运维之 间
开发 和测试之间也一样离不开紧密的协作
DevOps 的核心文化是不同职能工种之间的紧密协作的文化
在日常工作中包容错误、对事不对人
能对项目的开发流程持续改进，鼓励创新
积极拥抱这样的跨职能协作的文化
培养跨职能协作的文化
应用价值
需要去构建自动化部署的系统，从构建、测试到部署实现高度的自动化
建立数据监控的系统，让信息透明可测量;
最后要形成跨职能协作的文化
自动化、信息透明可测量、构建协作文化
不需要你改变开发模式，瀑布模 型或者敏捷开发都可以实施
不需要靠管理层推动
也不一定要让开发人员去学习运维知识 或者运维去学习开发知识
而是通过了解 DevOps 的核心价值，也就是跨职能之间紧密协 作，更快更可靠地构建、测试和发布软件，一点一点地做出改变
实践原则
关于持续集成和持续交付，不仅仅是工具的使用，同时还是基于工具之上的一整套的交付工 作流程
1、DevOps 工程师要帮助团队建立基于持续集成和持续交付工作流程
当数据异常，超出阈值，就马上触发报警，然后进入应急响应的流程
怎么第一时间恢复应该有准备
1、第一时间通知最合适的人去处理
2、涉及跨部门协作也应该有相应的配合流程;
3、对于故障应该有总结，避免类似情况再次发生
响应流程
将应用程序还有运行环境的各项数据监控起来，设置报警的阈值
2、要建立一套基于日志的监控报警的系统，以及故障响应的流程
云计算和虚拟化技术方面的技术，其实是横跨开发和运维的
只要通过 API 或脚本即可搭建应用
只要通过脚本和工具即可管理
构建出来基于云计算和虚拟化技术的基础设施后
3、要构建基于云计算和虚拟化技术的基础设施
帮助开发和运维在一起协作时多 沟通，相互学习
出现问题不指责，而是分析原因，共同承担责任，找出改进的方案
DevOps 工程师要帮助开发和运维相互理解对方的工作
4、要形成 DevOps 的文化
岗位职责
打造一应俱全的运维平台，降低交付难度，提升运维自动化、智能化，提高运维效率，提升业务连续性和安全性
规划目标
混合云
私有云
虚拟化
容器化
主机环境多样性，难以统一管理
业务变更难度较大，自动编排能力较低
业务状态监控，多平台难以数据联动
业务出现异常，难以实现故障自愈
业务运行状态，难以评估，更难以分析
运维知识匮乏，缺少专家指导及专家解决方案
运维痛点
纳管主机资源，实时监控主机运行状态，可在线管理、在线连接终端等
CentOS 6/7
UOS
服务器
Windows
智能硬件
主机分类
主机管理
安装部署
变更发布
弹性扩缩容
在线配置
性能优化
平台已内置常用基础组件，也支持符合标准的自研服务发布到应用商店，从而提供便捷的应用管理
应用管理
涵盖标准监控、定制监控、链路监控、智能监控等多种业务场景
应用监控
支持在线修改配置、远程启动、日志分析等
在线链接智能终端设备远程部署或升级终端应用
远程部署
当业务系统出现异常或故障时，可按照预定的自愈策略进行故障治理，极大降低故障对业务影响，减少企业损失
故障自愈
自动、手动进行业务指标、运行状态汇总，支持自动发送报告到指定邮箱
状态巡检
针对核心数据进行本地+异地备份，支持自动执行备份并将数据发送至备份服务器，达到异地的存储效果，确保数据安全
备份/恢复
提供运维常用工具、命令、脚本、SQL等，为日常运维操作提供便利，减少误操作、减低技术门槛，支持自行维护、扩充更多工具
精简工具
积累运维常用知识、技术、架构、解决方案等，支持自行维护、扩充文库内容
知识文库
用大屏来展示最核心的运营状态
运维大屏
方便的维护一些周期性的任务
任务调度
客服机器人
智能运维
核心功能
https://www.spug.cc/docs/about-spug/
Spug
http://omp.cloudwise.com/#/login
OMP
https://github.com/dianping/cat
CAT
https://github.com/smallmi/mysqltools
mysqltools
开源系统
技术运维平台
技术运维平台选型思考2023
0 条评论
回复 删除
下一页
