求职意向
运维主管 北京 薪资面议 随时到岗
教育背景
2020.x -2020x 锤子简历大学 计算机科学与技术
工作经验
2020.x -2020x 锤子简历信息技术有限公司 运维主管
工作描述：
1.负责运维团队的招聘，考核，和稳定性管理。
2.为公司业务平台的高可用、高性能、高并发提供运维支撑保障。
3.负责和各组负责人沟通协调需求，资源合理规划，保障运维工作，开发工作，测试工作高效进行，高效生产。
4.公司网站架构重组，持续演进和优化，提升公司提升整体业务的稳定性。
5.完善监控报警系统，发现和改进服务器的性能问题，并对服务器性能指标进行监控。
6.针对收集的服务器性能指标，对线上业务的出现的紧急问题，做出合理的处理，并在前期对服务器资源做出合理的利用，对可能出现的问题做出合理的规避。
7.完善高可用集群环境，负责codis集群/mysql读写分离集群/es集群/mongodb分片集群的运维调优及故障应急响应和排除并制定数据出入规则，约束开发人员对此类数据集群的操作。
8.指导编写各种系统脚本，服务器部署架构的研究和优化，对业界的新技术持续学习
2020.x -2020x 锤子简历信息技术有限公司 系统工程师
工作描述：
1. 钻研、应用、分享新技术。
2. 负责和各个项目开发人员沟通与协调需求
3. 和相关项目开发人员确定运维需求，优化系统架构和流程。
4. 代码发布的优化与和相关开发人员沟通项目需求做持续集成发布
5. 负责Linux常用软件和服务的安装和日常维护，系统优化，排查疑难问题等。
6. 负责搭建业务所需系统和平台，升缩扩展以及持续的调优
2020.x -2020x 百度彩票 系统工程师
工作描述：
1. 公司内网vpn的搭建、管理与维护。
2. 通过jenkins对项目代码做日常的发布与管理。
3.公司的监控系统的日常监控及维护。
4.管理与维护Kickstart，同时按需求优化无人值守安装。
5.为公司的java、php项目提供环境的搭建、维护、优化支持。
6.根据项目需求，搭建高可用的数据库环境，分布式存储环境。
7.根据业务流量的增加扩展，为公司项目增加高可用的高并发的负载均衡环境。为单点项目提供集群支持。
项目经验
2020.x -2020x 大锤数据库主从切换 运维主管
需求
公司数据库磁盘报警，只剩余20%(20G),删除binlog或者删除历史数据已经无法缓解此磁盘压力。
运维方案：
手工切换数据集群主从，永久性解决此磁盘压力，
1.其中主从切换，需要开发和测试同学验证数据完整性
2.主从切换需要停止运营的业务，和预估切换时间
3.汇总数据集群各节点的使用情况，和切换后恢复预案
4.汇总相关业务线使用该数据集群和需要修改的配置文件
5.经领导同意后运维发出主从集群迁移维护通告
6.新的主节点准备
7.编写数据集群操作细节，并反复与参与切换的运维同学讲解和了解不懂之处，确保切换无其它操作
8.与开发组/测试组/大数据组/讲解主从切换方案/各组同学自身的难点和需要大家配合之处
9.经协商确定主从切换时间，再次发出邮件通知公司，停止运营通告
10.主从切换
2020.x -2020x 加密接口开发 运维主管
需求
由于公司经营的特殊性，大锤的数据会有身份三要素数据，而2019年国家对个人信息泄漏管理严格，公司需要将此类数据加密或者脱敏处理，而数据的使用和加密都由开发人员来处理，还是会有泄密的风险，领导决定此加密由运维实现
实现：
1.和领导确定加密协议
2.确定调用方式为api接口方式。
3.自主决定开发语言为python
4.在django中开发加密接口。此加密分为加密接口和解密接口
5.编写dockerfile将此加密接口封装为容器.方便部署和调用
6.发出提测邮件，由测试同学作性能压测，暂支持性能为1400的QPS，并且有上升空间
7.发出邮件，将此加密接口交付大数据组调用
2020.x -2020x 特殊名单各家机构实际请求次数统计 运维主管
需求：
特殊名单是公司一个24小时提供查询的，在公司账单核对时发现部分机构的查询账单有出入，公司希望有个实际的生产数据：项目入口处各家机构实际请求次数，业务代码处理的各家机构请求次数，数据后段处理的各家机构处理次数
1.项目入口处各家机构实际请求次数数据由运维统计提供，业务代码处理的各家机构请求次数由java开发同学提供，数据后端的各家机构处理次数由大数据同学提供。
2.经过沟通后，此数据将在codis的hash表存储，name为机构的名字和当天的日期，对应的dic中存储着，项目入口处各家机构实际请求次数，业务代码处理的各家机构请求次数，数据后段处理的各家机构处理次数
3.大数据组将获取此数据在监控页面中展示。
实现：使用python为开发语言
1.连接mysql使用sql语句查询已经储存的各家机构名和对应的机构白名单
2.获取项目入口每天日志中业务接口查询日志条数，并获取这每条日志的ip，加入在线列表中
3.获取每家机构的ip在日志中出现的次数，将数据写入codis(redis)中
2020.x -2020x 安全组件开发 运维主管
需求：
公司经常受到国外公网异常流量攻击
1当攻击发生时，相关上联接口下的业务都将受到影响，需要紧急联系机房拉升机房带宽确保业务的快速恢复，
2.需要手工登陆服务器使用iftop查看大流量ip，并手工加入防火墙封禁处理。
实现：
1.使用python调用iftop，获取大流量的ip地址，并获取此ip的流量实际大小
2.白名单获取，读取此组件的各项目日志，获取日志中的业务相关ip，并将ip存储到codis(redis)库中
3.异常判定，此ip流量是否超过安全阀值，如不过，放行，如超过阀值，和codis(redis)库中的白名单做对比判断，如此ip在白名单列表中，放行，如不在白名单列表中，并且还超过安全阀值，加入iptables封禁处理
2020.x -2020x 架构演进之es集群 运维主管
需求：
公司将部分特殊的名单的数据加密和存储交给大数据组维护，而存储选型为es
实现：
1.采用3台机器部署es集群，当时的es版本为6.x,在不考虑最新版本的情况下，版本选型为5.6.5。
2.部署完成后的es集群运维和维护全部交付给大数据组。
3.大数据组自己运维和维护的es集群在初期取得了很大的项目成效。
4.随着业务的QPS越来越大，es集群的压力一样增大，有一天es集群宕机啦，并且无法启动，运维组收到大数据组的帮助请求，在运维组的帮助下，es重新启动完毕
5.大数据组单方面希望运维组接手此时的es黑盒运维。在双方沟通，并且和领导沟通后，运维组接手es的白盒运维，大数据组需要交接es的数据存储模式，数据修改周期，业务查询的高峰期，资源的回收使用等等，并且有相关的开发和存储需要和运维组沟通。不可单方面修改
6.在分析了大数据组的对es使用情况后，发现大数据组对es只有资源的使用开发，并没有做任何的资源回收维护，es宕机可能和这个状态相关
7.运维组开发出es资源回收程序，在每日的es使用低峰期主动对es集群的可回收资源进行回收。
8.相关文档整理，存档，
2020.x -2020x 架构演进之mongodb分片集群 系统工程师
需求:
公司to c的催收系统和官网系统在承接生产流量时，大量的sql查询和写入,并且部分业务业务数据对实时的有效性要求较高，因此由于历史原因有大量的慢查询，主库查询，对读写分离的mysql压力很大，并且影响催收员和公司运营人员的工作效率,在经过和领导的多次沟通下，将催收系统的部分实时性要求高的和部分其他数据由mysql迁入mongodb分片集群，再异步将数据同步到mysql。
实现：
1采用3台机器互为主备相互分片的模式，部署催收系统分片集群。
2.初期版本接入催收系统的mongdb分片集群效果很好，并且很快得到催收员/运营人员还有领导的认可。
3.官网系统亦采用3台机器的模式部署mongob分片集群。
3.而因为催收系统的mongodb不单单是只进行数据展示的查询使用，而是主要是增删改查的操作，在运行一段时间后，在业务的高峰时段会出现延迟，页面展示为转圈。分析日志结果为mongodb数据导致
4.分析mogodb分布式文件存储的数据库，那么mongodb对服务器的磁盘依赖很高。
5.获取服务器的磁盘io监控数据，在业务系统出现异常时，mongodb分片集群所在的服务器，磁盘io飙升，读的io和写的io都很高。
6.内部数据分析，db中的单集合整体很大，而db本身是分片存储的，发现集合本身不是随着db分片而分片。集合的分片有基于范围的分片和哈希的分片，分片依赖分片键，并且分片健分为递增行，随机行，混合型，在和开发确认了mongodb数据的存储模式和实际的存储内容后，确定集合的分片采取分片键为随机型的哈希型的分片是符合业务的时间情况的。
7.催收业务发展越来越好，催收系统对接的mongodb分片集群动态扩展升级，官网暂无需升级，
8.相关文档整理，存档
2020.x -2020x 架构演进之codis集群 系统工程师
需求：
公司to b的业务特殊名单查询系统的面向用户是承接各大甲方的24小时不间断查询，初期是最大的查询方是微博，项目的初期查询是以请求直接查询mysql的读写分离集群。这样持续的查询对项目的压力过大，其中像项目的线程，和数据库之间的连接，内存等等都是考验，为此，项目在研发正常的业务系统的同时，同时研发了一个黑洞项目，此项目的功能就是快速接受请求并返回结果，业务系统正常查询数据库并返回查询结果，两者同时挂载在前端项目入口，其中黑洞项目承接60%的权重，正常的业务系统，只承接40%的业务权重。特殊名单系统需要一个能够承载大流量并且快速返回查询的后端数据系统。
实现：
1.选用codis集群，并没有选用原版的redis集群，Codis由豌豆荚于2014年11月开源，基于Go和C开发。
2.项目初期codis集群部署在两台服务器上面，并且这两台服务器还有其他非codis的服务在运行，因此此时的codis集群，稳定性并不是特别乐观，在和特殊名单系统对接后，在业务压测的情况下，只能承载400的业务QPS查询，但是此时的特殊名单系统，依赖codis缓存集群，已经可以脱离黑洞项目独立承载甲方的查询请求。
3.初版的codis集群本身的稳定性和QPS不满足后续的业务发展需求，新的codis集群，在服务架构的时，升级得到同意，以6台服务器组成的集群，并且前端增加了haproxy+keelived，后端的codis各组接口件合理的拆分到各服务器上部署，并且单独的单独的codis本身的压测已到达12k+的稳定QPS，业务的压测已是业务的代码层崩溃，后端codis缓存层无异常。
4.项目文件的整理，存档。现特殊名单系统承载的甲方已增加，其中还有银行的查询，codis集群现无异常。
2020.x -2020x 架构演进之大用户下的openvpn系统 系统工程师
需求:
公司和国美有对接合作，由于业务的特殊性，国美的催收系统并未在公网暴露，需要将公司运营的催收机构的流量转接到国美的内网催收系统工作，并且下游的催收业务员远超单实例的openvpn实例。
实现：
1.采用国美的设备建议，公司与国美间的对接采用华为防火墙互为热备部署IPsec VPN对接。
2.在公司服务器上部署按机构部署openvpn实例，当机构本身的人数超过openvpn的实例所能承载的人数后，可以扩增实例，有新的机构亦可扩增实例，满足业务需求。
2020.x -2020x 锤子简历信息技术有限公司 系统工程师
需求：公司机房升级扩容，业务拆分和增加，其中增加to c的业务，需要拆分to B的业务
实现：
1.原来的公司业务都集中在有限的几台服务器上面，流量入口、web应用，数据端，测试环境，混杂严重。
2.设计新的网站架构图，将to c催收系统。to c的vpn的服务端，to b的特殊名单查询系统，hadoop集群环境，官网及其他web组件的流量入口，web应用端，数据端，物理独立开来，互不影响。
3.前端流量入口采用nginx+keepalived的架构模式，后面接入tomcat服务，to b业务，后面接入读写分离的mysql和codis缓存，to c的业务后面接入读写分离的mysql和monggodb分片集群，其中催收系统和官网的mysql和mongodb独立隔离，互不影响。
4.to c的vpn的服务端采用多实例的部署方案，突破单实例用户数限制，达到上千的用户规模，并且还有动态扩展空间。
5.外网流量和各项目的独立外网交换机连接，所有服务器的内网流量在同一个内网交换机下交互。
自我评价
我是一个技术人员，从事的是一个服务性的岗位，我必须用我手中所掌握的技术去去解决故障问题，同时与公司同事的关系非常融洽，同时也能通过各种途径学习新的技术知识。提高自己的能力
内容来源说明：本文章来自网络收集，如侵犯了你的权益，请联系QQ:2772182309进行删除。
https://www.100chui.com/article/51638.html
