当前位置:澳门贵宾厅 > www.vip8888.com > 网络 系统 数据库 开发 云计算 自动化 运维管理,其实还有一个大家都赞同的目标就是为了线上运行
网络 系统 数据库 开发 云计算 自动化 运维管理,其实还有一个大家都赞同的目标就是为了线上运行
2020-03-23

我们该怎么做?

运维自动化发展-web化

运维平台
例子:Job管理平台

DNSWeb管理 bind-DLZ
负载均衡Web管理
Job管理平台
监控平台 zabbix
操作系统安装平台

现在大家都在讨论DevOps,回忆过去,在2011年我还不了解DevOps的时候,开发和运维是如何协作的呢?我提出了自己的想法:面向运维的开发!

运维自动化发展-服务化(API)

智能化实现

可运维的标准?

网络 系统 数据库 开发 云计算 自动化 运维管理,其实还有一个大家都赞同的目标就是为了线上运行。运维自动化发展-工具化

工具化:

目标:

工具化和标准化是好搭档

痛点:

例子:

比如某天我们要对一个数据库从库进行版本停机升级。那么要求评估:
停机影响:
3:00 晚上有定时任务连接该数据库,做数据报表统计

下面我简单的列举了一些我们要做的事情,当然不仅仅这些:

运维标准化

物理设备层面:
1.服务器标签化、设备负责人、设备采购详情、设备摆放标准
2.网络划分、远程控制卡、网卡端口
3.服务器机型、硬盘、内存统一,根据业务分类
4.资产命名规范、编号规范、类型规范
5.监控标准

操作系统层面
1.操作系统版本
2.系统初始化(配置DNS、NTP、内核参数调优)
3.基础Agent配备(Zabbix agent、logstash agent、salt minion)
4.系统监控标准(CPU、内存、硬盘、网络、进程)

应用服务层面:
1.Web服务器选型(nginx、Apache)
2.进程启动用户、端口监听规范、日志收集规范(访问日志、错误日志、运行日志)
3.配置管理(配置文件规范、脚本规范)
4.架构规范(Nginx+keepalived、LVS+keepalived等等)
5.部署规范(位置、包命名等)

运维操作层面:
1.机房巡检流程(周期、内容、保修流程)
2.业务部署流程(先测试、后生产。回滚)
3.故障处理流程(紧急处理、故障升级、重大故障处理)
4.工作日志流程(如何编写工作日志)
5.业务上线流程(1.项目发起人 2.系统安装 3.部署nginx 4.解析域名 5.测试 6.加监控)
6.业务下线流程(谁发起,数据如何处理)
7.运维安全规范(密码复杂度、更改周期、VPN使用规范、服务登陆规范、rm命令的参数写在最后面)

标准化:规范化 流程化 文档化

目标:文档化

这个观点有点骇然,其实意义很简单就是想在项目开始初期时运维就要参与进来,制定相关的标准和规范,开发在编码过程中要遵守这些标准和规范,满足运维提出的“可运维”的要求。因为我们的目标都是为了项目上线后可以更快、更稳定、更安全的运行,这个目标肯定会得到多个部门和领导的支持。

运维自动化发展

提前建立运维体系:包括但不局限于多维监控、安全、备份、负载均衡、日志平台、部署系统等。了解业务:尤其是做应用运维,不懂业务就是耍流氓嘛。参与需求评审:项目开始在需求评审阶段,把运维的标准化要求提出来,一起探讨。主动沟通:在中小企业运维往往被忽视,那么就需要我们主动去沟通。

运维自动化发展-智能化

运维自动化发展层级:

智能化的自动化扩容、缩容、服务降级、故障自愈

自动化扩容
1.zabbix触发Action
触发条件和决策:

创建虚拟机之前,先判断Buffer是否有最近X小时已经存在之前已经移除的虚拟机,并查询软件版本是否和当前一致,如果一致,跳过234步,如果不一致,跳过23步

2.Openstack 创建虚拟机
3.Saltstack 配置环境
4.部署系统 部署当前代码
5.测试服务是否可用(注意间隔和次数)
6.加入集群
7.通知(短信、邮件)

自动化缩容

部署:环境规划、代码托管、自动化部署、差异配置文件处理等。监控:某个新业务上线,是否能够有效的监控、如何知道某个接口被调用的多少次?安全:都谁可以调用本业务的接口?,能调用多少次?。备份:该业务是否可以做负载均衡?负载均衡需要考虑什么?日志:该业务都产生哪些日志?日志如何收集、日志如何归档、日志保留时间。

运维和发展的一个线路

云计算的核心竞争力是运维!

系统架构师(偏管理):网络 系统 数据库 开发 云计算 自动化 运维管理 服务管理 项目管理 测试 业务
专注于某一领域
解决方案架构师

我相信在中小企业,很多运维人员都往往都是在业务上线后,才开始考虑这些问题,运维会处于一个完全被动的局面。所以我们要主动出击,那么在项目初期,运维要把我们的运维相关的需求告知项目负责人和相关领导。

运维工作内容分类

阿里云:
SLB LVS + Tengine(Nginx)
ECS KVM

原文来自:运维社区

我们试想一下,我们研发人员编写代码是为了什么?为了实现业务逻辑?实现业务功能?满足某些业务需求?这些都没错。其实还有一个大家都赞同的目标就是为了线上运行!那么既然是为了线上运行,是不是应该按照线上运行的规范来着手开发呢?貌似一下子就把开发套进去了,哈哈。

都是套路

总结起来就是说开发、运维双方进行协商,解决这些问题。例如开发可以编写一个API,我们通过API可以进行性能监控,或者程序内部实现ACL等类似的沟通。

针对可运维的标准要看具体情况,不同的团队、业务都有不同的标准。例如我之前就是在这几个方面来着手制定“可运维”。

前言