云运维组2023年度工作计划

要离职了，回头翻看到2022年10月写的2023年度工作计划，顺手发上来

1 开发运维平台

现在有新旧服务约210个，这是从jenkins构建平台上一个个统计的，只知道有这些项目存在，但项目的其他信息，如负责人员、服务功能、对应域名等都不清楚，出现问题不方便追溯，就需要一个运维平台来管理统计这些项目，记录这些项目对应的信息。

除项目统计外，还有各运维流程中的信息需要统筹。

运维平台常见功能：项目管理、资产统计、云费用使用统计、权限审批、加解密管理、第三方平台对接管理等常见的运维管理功能

2 完善CICD流程，提高运维效率

现CI流程使用的工具是jenkins，构建、部署是各自流程分开的，使用的是Publish Over SSH、Promoted builds插件

无CD流程

后续改进：

引入钩子配置，实现自动化CD

权限分配，可追溯

实现灰度分布

考察jenkins外的DevOps工具

3 完善监控系统，监控系统平台化

现在监控系统有腾讯云监控、zabbix，链路监控有skywalking

目前监控项有：资源监控、生产域名4xx监控、进程存活监控

后续改进：

1. 搭建Prometheus监控，结合skywalking，加入应用层各自监控项，实现对微服务应用接 口、数据库、缓存、中间件、流量、qps等监控
2. 将监控系统平台化，并与日志系统结合，实现对业务指标监控

4 完善日志系统

现在生产日志系统使用的是click house，大致流程如下：

 logs-->nfs-->filebeat.yml-->server-log-all topic-->logstash-->不同项目组topic-->clickhouse

优化点：

Clickhouse有延迟1-5分钟，不方便实时查找

所有服务输出到一个topic中，有日志流失情况

后续改进：

1. 日志输出topic由一个分开到多个，每个业务中一个日志输出topic
2. 调研其他日志系统
3. 日志系统接入到监控系统中，实现业务日志+指标/关键字监控+大数据分析展示

5 运维架构优化

现在整体运维架构如下：jar--docker--k8s(pod)--service--nginx--lb--url

瓶颈：外层nginx是所有服务共用的，nginx出现问题，所过此nginx的业务都会受影响

后续改进：改使用k8s的ingress-nginx，这会每个业务名称空间分开，各个业务互不影响。

还有些服务使用的是java -jar部署方式，后续考虑改进为docker 部署的，或者考虑非生产环境上k8s，实现业务全面容器化。

K8s容器集群采用的是腾讯云的TKE平台，后续跟腾讯云沟通，看容器集群是否有可优化的方向，如存储、网络、调度等。

6 腾讯云网络优化

现在腾讯云资源网络生产环境非生产环境是放在同网络区的，没有区分，非生产环境可以调用生产环境，缺乏安全性；

后续想分开，将生产环境和非生产环境隔离，现有生产资源网络区不迁移，迁移非生产环境资源网络区的。

现在正常进行的网络区迁移工作，就开始分开不同环境不同的网络区了。

7 现有资源优化

跟开发组长确认每个服务需要使用多少内存、cpu，合理规划资源分配，将服务整合；

Java服务使用高内存优化：历史开发版本原因，现有不少java服务使用的内存很高，后续会跟开发对接，找到问题处理所在，处理掉。