求职贴：运维开发｜SRE

已经拿到 offer 找到工作了 2021-09-27

最近开始准备找工作和面试，奈何一直想去的那家公司没有 HC，再加上 10 月国庆回来之后房租就要到期，要在国庆放假前决定去哪个城市。所以最近有点焦虑担心国庆前拿到自己心仪的 offer 有一定的风险，因此就发篇求职贴，如贵司还需要我这样的运维开发或 SRE 不妨看下如何 😂。

个人经历

2019 年本科毕业，毕业之后去了一家国企工作，做传统的机房运维和公司的业务容器化转型上 K8s 的事情。在国企里面 955 的日子过得确实比较舒服，但考虑到技术氛围以及长期的发展，最终还是在去年 5 月份离职来到了杭州，入职了一家做 PaaS toB 产品的公司。不幸的是入职不久后公司又被字节跳动给收购了，从那之后就开始被迫跳动到今年的 7 月底离职。至于离职的原因主要是薪资和职级不太满意，想换个环境心安理得地拿一份与自己能力相匹配的薪水，其他同事离职大多也是因为这个原因。

离职这段时间一直在家休息，看书和学习。虽然毕业已经两年了，但仍有很多想要学习和了解的知识，不仅仅是技术这一层面，在其他领域比如古生物学、演化生物学这些自己一直都很想了解，这段时间看了大量的书籍和科普纪录片，增加了很多没用的知识。人总不能为了赚钱而活，多少有点属于自己的空间，满足自己的求知欲和好奇心，这样生活才能充满乐趣。

当然这段时间也没白闲着，花了两周左右的时间完成了两个开源项目：一个是用于构建 yum/apt/dnf 离线源的工具 k8sli/os-packages ，以及无网环境中离线部署 k8s 的工具 k8sli/kubeplay 。

工作经历

离职前在字节跳动负责的工作事项偏向于运维开发或SRE：

版本发布

这块主要是负责 PaaS toB 产品 (Compass 和 Clever) 的版本发布工作。在开发团队规模较小的场景下这块其实并不太重要，几个开发搞一搞就完事儿了。但等到产品功能越来越复杂、所涉及的代码仓库越来越多、开发人员越来越多的时候，就需要有一套标准的版本发布流程和一些公共事务规范去协调这部分的工作了。我就是负责这块内容的，要和 RD、PM、PD、QA 各个角色的负责人对接以及各种无厘头的扯皮，总结起来三个字事儿多。其实这部分工作内容和 PingCAP 曾提到的 Behind TiDB 5.0 - 聊聊 PingCAP 的工程体系 有相似之处。之前我也写过一篇博客 云原生 PaaS 产品发布&部署方案，感兴趣的可以读一下。

运维部署

主要是负责开发平台底层 K8s 集群部署工具以及平台组件部署工具。有点类似于 Kubesphere 中负责集群部署的 kubekey 和负责平台组件部署的 ks-installer 。不同于 ks-installer 为每个平台组件单独写一些 ansible 的 playbook 来完成平台组件部署，我们的平台组件部署工具是使用 helm chart 统一部署的。这样维护起来也更加方便，因为所有的平台组件部署都是 helm chart，这样版本发布、自动化打包以及后续的部署，这一整套都能统一在一起，维护的成本也比低。这部分内容可参考我写的博客：

发布流水线

不同于传统的发布流水线，toB 产品的发布流水线主要是完成离线安装包的打包，然后前线运维使用这个安装包在客户环境中进行实施部署。从去年入职到今年 7 月底离职这段时间，不断地对产品的发布流水线进行打磨和优化，到我离职时基本上所有的代码都完全重构了，发布效率和性能也得到了质的提升。尤其是 overlay2 在打包发布流水线中的应用 中提到使用 overlay2 这种独特的方案，硬是将镜像同步的性能提升了 15 倍，在那段时间也学到了特别多的东西，收获颇丰。这部分内容可以参考我之前写的博客：

On-call 技术支持

这部分就是一些前线运维的 On-call 技术支持了，一般客户不会直接找到产品研发，而是通过前线运维实施的人员来找我们解决问题的。在这期间就自己维护这一个产品的运维部署 QA 文档，将产品以及有关 K8s 方面的问题大致地梳理总结了一下。如果其他同事或前线运维实施人员遇到同样的问题，在飞书上搜索就能检索到，也能帮助一下别人吧。这基本上都是我自己一个人维护的，之前我就一直很纳闷为什么没有这种文档，产品这么多问题也不梳理总结一下 😤，只有我来了之后才有这种文档，不过离职后有没有人在继续维护就不得而知了。

总之，个人在工作上还算用心吧，一些总结和梳理工作都是自己默默完成的（虽然 OKR 或者绩效评估时这些也无法体现出来）。有时候为了验证一个想法或方案也常常半夜一两点从床上爬起来到电脑桌旁一顿 xjb 搞。

之前在看 PingCAP 招聘 的职位时就发现一些职位和自己做的十分相似，自己所负责的工作事项在 PingCAP 都有单独的职位：比如负责平台组件部署的自动化运维研发工程师；负责产品版本发布的 Release Manager；负责组件 CI/CD 自动化流水线的 Site Reliability Engineer；负责 On-call 的 售后技术支持；

突然意识到自己一个人完成四种职能的工作 😂，可能是因为我们的产品还不算太复杂，没有 PingCAP 规模那么大，做的内容也没有那么精细，所以自己一个人 take 起来这些工作事项也没问题。这还不是因为年初的时候组织架构大调整导致之前的业务小组解散，整个小组遗留的工作都落在了我一个人身上，所以就一个人干完了这么多人做的事儿。想想自己一个人能 take 起来四个人的活儿，拿那么点的薪资就可气😡，不离职才怪。

技术能力

  • 大学时就喜欢玩 Linux ，接触一些开源社区向大佬们学习。常见的 Linux 发行版如 CentOS、Ubuntu、Debian 基本的运维管理掌握的还算可以，日常的开发测试都在这些发行版上搞，也在这些发行版上是适配过 K8s 部署。一些常见的自动化运维工具如 Ansible、Terraform 等自己都是日常使用，掌握的还行。

  • 对 IaaS 虚拟化有些了解，日常使用 ESXi 作为 NAS 主机 OS ，上面开了一些虚拟机跑了一些服务；使用 Proxmox VE/KVM 作为开发测试环境，qemu 和 cloud-init 管理虚拟机那是真香。

  • 深入研究过容器镜像构建、存储、分发的流程和原理，并将其应用在产品的打包发布流水线中以提升产品发布效率。

  • 熟悉云原生 PaaS ToB 产品版本发布和私有化交付全流程； 曾为近 20 个客户主导完成 50 多个 OEM 定制化补丁包版本发布，拥有一定的 ToB 项目管理经验； 能够推动并落地一些提升产品研发效率的公共事务规范，解决产品私有化交付过程中的遇到的痛点。

  • 掌握了 Python、Shell、Ansible 编程，给 kubernetes 社区的 kubespray 项目贡献过十几个 PR。

  • 至于 Golang 目前还在学习中，算是掌握了一些基本的语法和数据结构。年初的时候写过一个 CLI 工具，使用 go-gitlab 库进行 CRUD 操作，从 Gitlab repo 中获某个 tag 下的一些特定目录下的文件。当时体会到了写 Go 的乐趣，不过后来因为工作的原因很少会用 Go 写代码，基本上都是自己慢慢摸索着学。

  • 能够使用 Jenkins、Gitlab CI、GitHub Actions 等工具为平台组件及产品构建 CI/CD 流水线、私有化打包发布流水线。

  • 拥有腾讯云、GCP、AWS、Oracle 等云服务器，具备高速稳定的科学上网环境； 业余喜欢折腾 NAS 存储、虚拟化、OpenWrt 软路由。

  • 文档写作能力还行，最近几个月一直坚持每月写至少两篇博客，之前在字节的时候也是负责撰写产品的各种文档，如安装手册、运维手册、实施方案、QA 文档等。

  • 业余时间喜欢阅读大佬们的技术博客、收藏博客文章；自己也时常写博客，并以 k8s.li 作为个人域名（日均 1.3K UV）；在云原生实验室、K8sMeetup、CNCF 等公众号投稿过至少 12 篇个人原创技术文章。

  • 对技术一直保持着好奇心和求知欲，经常参加过一些像 CNCF、Rancher、青云 kubesphere 等社区举办的活动，向大佬们学习经验。

个人作品

  • k8sli/kubeplay：无网环境中 K8s 离线部署的工具
  • registry-mirrors：使用 GitHub actions 自动同步镜像的工具
  • k8sli/os-packages：yum/dnf/apt 离线源自动化构建工具
  • tg.k8s.li：Kubernetes 相关 RSS 频道，订阅人数 1300+，欢迎小伙伴们加入：）
  • kindle ：将 Kindle 上 .txt 格式的标注文本转换成 .html 的 Python 脚本

其他

工作城市

期望的工作地区最好是杭州或上海；full remote 也可以哇；深圳/广州/成都因为搬家不方便我会考虑下；北京实在不想去，感觉在那儿生活不太习惯；其他城市看情况。

联系方式

最好能先提供一下贵司官网或者其他招聘网站上的 JD 链接，我需要看一下自己是否能符合要求，如果合适的话就将简历发送到大佬您的邮箱（最好是公司的域名邮箱）。