【运维趟坑回忆录 开篇】初入初创, 一脸懵逼

2024-06-16 17:18

本文主要是介绍【运维趟坑回忆录 开篇】初入初创, 一脸懵逼,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

距离vpc和容器化过去了快一年, 一直想要完整回顾梳理下整个过程, 最近准备进行swarm->kubernetes的二次迁移, 正好借由这次契机重新回顾下这段历从最初原始时代到vpc,swarm容器化到k8s的经历.

原始时代

16年7月从上家游戏公司离职, 来到了目前的互金公司, 成为唯一的运维, 此时公司java开发人数已经有几十人… 运维的技术栈也由php转移到了java, 刚开始的时候有些不适应和孤独感(只有自己一个运维, 交流主要就是招我进来同时也是前期负责运维这块的CIO, 刚开始下发完任务后交流也不多), 花了一段时间适应和熟悉后, 感觉问题颇多.

现状是开发同学有很多, 但是运维就一个, 初期运维这块内容由CIO兼顾, 同时CIO还是整个架构的主导者和主力程序员. 已有的100多个ECS由puppet下发配置, puppet agent默认半小时刷新一次.
应用类型主要为spring + dubbo, tomcat + nginx

比较关键的几个问题如下

  • 经典网络问题: 公司所有计算资源均在阿里云上, 不过阿里云当时并未推出vpc, 所有资源都在经典网络, 直接导致了如下的问题
    • 安全问题: 经典网络各租户ip之间并不能保证真正的隔离, 有一定风险, 不过CIO安全公司出身, 很强烈的安全意识, 所有ECS都开启了iptables, 只开放了自有节点的访问, 规则由puppet统一下发, 但是agent半小时才会自动刷新, 过程并无任何监控, 是否生效完全随缘, 而且puppet主机列表是手动维护的一个list文件, 漏没漏很难说.
    • 网段问题: 节点都是阿里云自动分配A段的随缘ip, 一个节点一个公网ip, 意味着出口ip各不相同, 新增一个节点, 要加一堆白名单(rds,drds,slb,nas等等),内部内网应用等资源还好说, 调用阿里云api还可以自动操作下, 要是涉及到第三方要报备的时间就很难控制了, 这个导致我们新增节点非常痛苦, 加一次白名单就很要命了, 只能提前部署好一些备机以防万一,平时在备机上跑一些不太重要的任务.
  • 项目部署, 有一个专门的编译服务器, 上面分了testbuilder和pordbuilder的用户, 对应测试和线上的构建用户, 开发同学自己登陆到编译服务器用脚本编译和拷贝到NFS目录, 然后到对应的测试或线上服务器一台一台的用NFS中的部署脚本部署
    • 各种冲突:
      • lib冲突: java同学抽出来的lib包很多, 虽然有maven私服, 但是所有java的lib包全部都是SNAPSHOT版本, 而且基本没有上传私服的习惯, 一旦有公共lib改动在测试环境编译了, 很容易就会导致其他开发同学躺枪.
      • 测试环境的资源冲突, 测试环境一共只有有4~5台服务器, 各种tomcat和端口满天飞, 根本无法识别, 该起的没起来, 本来应该停了的跑起来了.
      • 代码冲突: 部署脚本都是自己维护, 没有统一模板, 内容千奇百怪, 分支切来切去, 而且都是用的testbuilder和prodbuilder用户, 完全不知道谁之前到底干了啥, 代码冲突也经常发生, 维护完全靠自觉.
    • 发布太随意: 开发同学自己掌控线上服务器部署能力, 有时候发布略随意, 不吭声的把未充分测试代码发布到线上导致问题, 事后出现异常才体现出来
    • 环境不一致: lib包繁多并且都是SNAPSHOT版本,如果涉及改动的lib太多,测试环境测试正常版本的lib状态,到线上编译的时候不一定和测试一致,就会导致报错.
    • 发布时间太长: web基本项目都使用了slb, 部署的流程则是, slb权重调零->跑NFS里的部署脚本(停止应用, 备份老的代码, 从NFS复制新的代码, 启动应用)->挂回SLB,节点多的部署一次可能半小时就没了, 万一要是还有问题需要回滚, 或者高频次发布, 完全就耗在这种重复的事情上了.
  • 基础服务版本差异: 由于没有标准化模板, tomacat或者nginx之类的基础服务的版本也是千奇百怪, 当中配置文件的差异就更是玄学了
  • 权限控制:
    • 服务器权限: 有一个现成的中央跳板机, 每个开发同学有一个自己的账号, 应用服务器则是统一使用的xxxx用户, 能否登陆应用服务器, 取决于应用服务器上是否加了跳板机上对应开发的key,开发同学登陆到应用节点后基本就不可控了, 都是同一个账号, 无法区分谁干了啥. 而且当时puppet里面配置的分组只有测试和线上, 要是加一下登陆的key整个线上环境节点的登陆等于全开放了
    • 数据库权限: 由CIO直接在数据库开通个人的数据库账号, 通过跳板机创建ssh转发, 用内网ip以跳板机身份去访问RDS, 起了一个简单的tcpdump进程对内网网卡抓包,用perl分析,可以获取发出的明文sql,查起问题来很麻烦, 而且一般是事后了.
  • 配置管理:
    • 应用的文件配置: 各种properties文件, 项目内resource目录下分了common,dev,prod文件夹, mvn编译的时候传入参数类似 -Ddev 参数来获取对应环境的配置文件. 不过dev环境配置包括账密之类的都是直接写死在文件里提交git, 线上配置则是用占位符比如 {DB_PASSWORD},在编译节点部署的时候,通过脚本替换占位符替换为真实的值.不过既然能登陆编译服务器, 稍微机灵点的看下脚本内容就能找到有着所有明文配置的源配置文件…替换后的应用配置文件也依旧是明文的,到应用服务器或者NFS上还是一览无余, 加上服务器权限开得很奔放且无审计, 组合起来真是灾难. 想想万一有个好奇的看到了源文件配置好奇在服务器上连了下里面数据源或其他内容, 你怕不怕
    • 应用内的配置: 这种是应用在启动后读取的实时配置, 现成有个superdiamond,但是是单点的, 整个环境的应用配置都堆在一个页面, 页面加载都要等好久, 没有版本管理,不好回滚, 热加载也是随缘, 有时候改个配置还是要重启. 同样也有明文配置的问题.
  • 监控:
    • 业务监控: 有一个自研的业务监控系统
    • 系统监控: 基本没有.

上面这些问题刚开始的时候用一些粗暴的方式去缓解:

  • 监控: 部署zabbix对系统和进程信息进行监控, 加了发现规则自动获取tomcat进程加入监控(经常性线上应用跑挂了不知道, 这个效果还不错), puppet dashboard获取agent节点配置刷新的状态,至少改完配置后不是一脸懵逼傻傻的等, 有时候想要快速生效, 就直接用ansible去批量刷puppet agent.
  • 权限回收: 线上应用服务器权限回收, 对已有节点分组, 按需根据应用组或者项目组授权. 编译服务器权限线上编译账号prodbuilder权限回收重新分配, 让开发同学权限尽量最小化.
  • 流程和标准化:
    • 线上核心应用禁止私自部署, 统一提工单到运维同学, 周知项目相关同学, 由运维同学部署(导致的结果就很直接了,不少时间耗在这了,不过确实因为私下部署而导致问题的情况好了很多)
    • tomcat,nginx等应用版本和参数确定好作为模板后放到NFS,后续应用都由模板创建.
    • 线上发布的lib统一为master分支, 应用使用online分支.非充分测试的提交禁止合并到部署分支.后续比较重要应用的部署都是运维同学控制,还比较好控制.
  • 配置中心: 换成了spring cloud config, 有点重, gitlab全家桶加上开发同学自己写的客户端. 好处是依赖gitlab有了版本管理, 热加载不再是玄学, 但是依旧有着单点的问题,而且客户端不太稳定, 造成了几次大规模出错.
  • 提前部署: 需要报备三方的应用, 提前部署起来, 平时先不启动, 节点上可以先跑不太重要的服务.需要扩容的时候直接更新最新代码启动后挂载到对应slb提供服务.

探路

当然上面列出的都是缓兵之计, 大部分问题还是存在, 在前几个月懵逼和饱受白名单问题煎熬后, 慢慢打起了vpc迁移的算盘.

这个迁移很大的一个问题就是, 如何将VPC和经典资源打通呢? 详见下篇

这篇关于【运维趟坑回忆录 开篇】初入初创, 一脸懵逼的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1067057

相关文章

开篇: 为什么要做这个项目?

背景 最近工作中遇到一个需求需要实现一版在线的Web编辑器,类似 Vue Playground 的效果,但是Vue playground 整体体验下来不是很好,和本地 VSCode 编辑器开发体验差距较大(虽然理解在线编辑器没必要完全照着本地开发体验来)。 经过多方体验调研,发现目前的业界方案主要两种: 基于Monaco / Codemirror 实现,也是大多数场景使用的方案,但是效果却是参

浏览器工作原理(1)-开篇

本系列博客为学习《浏览器工作原理及实践》所笔记 开篇 浏览器的发展历程中的三个进化路线: 应用程序web化:B/S架构,视频、音频、游戏往web场景切换 web应用移动化:存在问题有渲染流程复杂,性能不够好,离线时用户无法使用,无法接受消息推送,不过PWA方案可以整合Web和本地程序的优势 Web操作系统化:两层含义:1 利用web技术构建一个纯粹的操作系统(ChromeOS);2

HBase抗战总结 | 阿里巴巴HBase高可用8年抗战回忆录

前言 2011年毕玄和竹庄两位大神将HBase引入阿里技术体系,2014年接力棒转到东8区第一位HBase commiter天梧手中,多年来与淘宝、旺旺、菜鸟、支付宝、高德、大文娱、阿里妈妈等几乎全BU合作伙伴携手共进,支撑了双十一大屏、支付宝账单、支付宝风控、物流详情等核心业务。2018年双十一,HBase全天处理请求2.4万亿行,单集群吞吐达到千万级别。从一个婴儿成长为青年,阿里HBase

Netty+Websocket 初入理解

Netty+Websocket 笔记 初入理解Netty+Websocket,需要了解其中的类和方法有什么作用,以下是自己总结的一些自己用到的: Channel 通信通道,代表一个socket链接 ChannelFuture 执行异步操作 ChannelPipeline 管道:每个Channel都有关联的ChannelPipeline,提供handler链的容器 Chann

基于JAVA+SpringBoot+Vue的大学校园回忆录系统

基于JAVA+SpringBoot+Vue的大学校园回忆录系统 前言 ✌全网粉丝20W+,csdn特邀作者、博客专家、CSDN[新星计划]导师、java领域优质创作者,博客之星、掘金/华为云/阿里云/InfoQ等平台优质作者、专注于Java技术领域和毕业项目实战✌ 🍅文末附源码下载链接🍅 哈喽兄弟们,好久不见哦~ 最近整理了一下之前写过的一些小项目/毕业设计。发现还是有很多存货

体育直播平台开发:初创公司突破资金与市场的双重挑战

在当今竞争激烈的数字娱乐行业中,体育直播平台的发展潜力巨大。然而,面对如此巨大的蓝海市场,对于初创公司或中小型平台而言,高昂的开发和运营成本可能成为进入该行业的主要障碍。本文将探讨一些可行的低成本开发策略,帮助企业在有限的资金压力下成功构建和运营体育直播平台。 1、MVP开发:专注核心功能 最低可行产品(MVP,Minimum Viable Product)开发是一种有效的策略,尤其适合预算

金融科技初创企业建设指南

金融科技领域正以前所未有的速度发展,重塑我们与金钱和金融服务的互动方式。随着我们迈向 2025 年,尖端技术的融合、不断变化的消费者期望以及全球对金融包容性的推动正在创造前所未有的机遇。创新者现在有独特的机会在金融科技领域留下自己的印记。 以下几个因素使得即将到来的一年成为开展金融科技企业的理想之年: 疫情后数字化转型加速: 超过 40% 的中低收入经济体成年人在疫情期间进行了首次数字支付。许

Unix环境高级编程开篇-apue.h配置

书就不多说了,被称为Unix下C编程的圣经;不过现在国内貌似部分人都喜欢向别人推荐书,我很怀疑着部分人是不是推荐的每一本都看过。这个我暂时也不敢推荐,因为我也没有看完。 这本书上几乎所有的代码都用到了作者编程的一个头文件:apue.h,但是这个不是ISO C自带的,所以需要配置一下。 我用的这本书是第三版,第三版,第三版 重要的事情说三遍 1:先去这本书的官网把源代码下载下来,传送门 2:

(一) 初入MySQL 【认识和部署】

前置资源 一、数据库概述 1.1、数据库基本概念 数据(Data)  描述事物的符号记录称为数据。数字、文字、图形、图像、声音、档案记录等都是数据。数据是以“记录”的形式按照统一的格式进行存储的,而不是杂乱无章的。 相同格式和类型的数据统一存放在一起,而不会把“人”和“书”混在一起存储。这样,数据的存储就能够井然有序。 表(行+列) 数据存储在表中记录:行字段(属性): 列 数据

Android 退出app方式(回忆录)

一、点击返回键或者设备back键调用finish private void back(){finish();}或@Overridepublic void onBackPressed() {super.onBackPressed();} 二、结束进程 android.os.Process.killProcess(android.os.Process.myPid()); 三、方法二exi