运维开发工程师( devops 工程师) 10k-20k

工作职责:

  1. 负责公司基于容器云产品的落地实施。
  2. 设计并开发配置管理、发布部署、监控等运维自动化系统。
  3. 负责基于开源工具集二次开发,对接平台接口。
  4. 推动产品的不断迭代,与项目组配合提出架构优化的方案。

任职要求:
5. 本科以上学历,对云计算(IaaS、PaaS、SaaS)及 DevOps 有一定的了解和见解
6. 熟练掌握 shell 或者 Python ,有 2 年以上的运维开发工作经验
7. 熟悉 Unix/Linux 操作系统;
8. 至少掌握一门静态语言 C/C++、Java、php、Go 等
9. 精通 Lvs、Nginx、Redis、MongoDB、MySQL 等服务调优和故障排除。
10. 熟悉 Python web 常用框架的优先,如 Django、Flask、Tornado 等

加分项:
11. 了解持续集成、持续部署( CI/CD )的优先
12. 了解分布式系统设计,有过相关研发经验的优先
13. 了解大数据处理、日志收集系统的优先,如 Kafka、Hadoop、Hive、Spark、Storm、ELK、Zookeeper 等。
14. 了解自动化运维发布部署、配置管理、监控等工具的优先,如 Puppet、Chef、Ansible、SaltStack、grafana、zabbix 等
15. 了解 Docker、Mesos、Swarm、Kubernetes 等容器编排调度工具的优先

自身经历总结,觉得一个优秀的运维开发工程师应当具备以下能力和素质。

  1. 提高运维意识。
    从下到上,从上到下的工作都要做好,对上运维工作的价值和含金量可以得到认可,对下我们的工作能够提高效率解放运维。
    运维意识是很重要,并不是你技术很牛,学的技术很多很熟,就不代表你不需要运维意识。
    其实领导很看重运维意识的,例如有没有做好备份,权限分配问题,平台测试情况,故障响应时间等,这些都是意识,而不是你学了很多技术自认大牛了,平台发现故障你又没什么大不子,以为很简单的问题喜欢处理就处理,不需要向其它部门反馈等,领导不是看你的技术如何,而是看你的运维意识如何,你没运维意识,技术再牛也没用,只会让其它部门的人跟你不协调。
  2. 了解业务场景
    DevOps平台最终服务于运维部和开发测试部同事,因此只有熟悉了解了每一项业务的运维场景,才能更好去设计功能与代码开发,熟悉业务场景才能方方面面考虑周全,开发出来的代码才能满足各类场景应用。
  3. 拒绝重复犯错
    人难免会犯错,这是无法避免的,我们应当根据已有的犯错经验,总结犯错的原因,以及如何避免同类情况再次发生,甚至可以把一些典型的错误在团队中分享,把一个人的错误得到的经验传播于整个团队。
  4. 凡事有备份,可回退
    运维工作中经常有一些发布,迁移,备份等复杂操作,因此,在研发DevOPs平台的时候,要做好全面的操作计划,思考每一步可能的回退与备份。
  5. 平台操作尽量简化
    DevOps平台目的就是为了能够提高运维的工作效率,解放运维,因此在设计与开发的时候,应当保持操作简单,不要让事情变得太复杂,能点一下到位的,尽量不要让人点五六下才能完成操作。
  6. 注重优化用户体验
    DevOps开发是一个迭代的过程,虽然我们常说以功能开发为主,但是用户体验也同等重要,试想一下,纵使你开发的功能众多,如果体验不友好,用户便失去了再次使用的欲望,如果用户拒绝,抵触使用平台,做再多功能也是失败,最终平台推广失败。因此,在研发的过程中,我们应当深入体验自己开发的产品,把自己当成用户去体验平台操作。尽可能的去优化用户体验。这是一个优秀的运维开发工程师必需要懂的。
    在设计与开发的过程中经常会碰到复杂,繁琐的场景,这个时候我们很容易失去耐心,我们要时刻提醒自己,必须严格履行自己的工作职责,端正自己的工作态度,做一件事,要么不做,既然做了就要做好:当你想要放弃的时候,想想当初为什么要开始。

对运维开发以及其职业发展的一些浅薄理解,总的来说,运维开发还是一个比较有意思且有良好发展的职业分支,虽然偶尔也要背黑锅,但也欢迎更多努力、聪明、有才华的同学加入运维开发行业。

无产品、无设计、需求也是靠业务运维和开发们的口头描述。

其中的核心功能:应用部署界面,在参考其它同类产品后,发现都不适合业务场景,要么功能太分散,要么就仅是流程控制。于是前端功能里,我们做了这些:

区分不同环境下的包,实现有序管理。
应用的状态可以通过界面做启停、查看配置等任务。
Jenkins服务操作可通过界面完成,简化配置工程师的工作。
业务运维与开发团队的日常发包工作界面化

此时一个优秀的运维开发需具备以下技能:产品规划、产品设计、面向对象、需求模型、领域模型、设计模型、设计原则、设计模式、产品工具和文档能力等。
所以,当运维需求被理解、分析得足够透彻,以及运维开发获得了「产品经理」能力后,运维开发就是一种普通的开发分支,按需求文档编码即可

其实「好使的DevOps系统」真正等价于「运维理解」+「开发能力」,这两种能力也是可以分离的,不一定要强加在运维开发工程师一个人的身上。
类似其他业务形态的开发过程,需要产品经理和程序员两种角色分离,企业也不会说要招聘既会写代码、又会出需求的程序员。
所以,当运维能把运维自动化的需求细致地文档化下来,把自动化系统的设计、架构等关键环节确立下来,这就是最好的「运维理解」。这时把这份靠谱、好使、细致的需求文档交给具备强「开发能力」的程序员,最终就可以得到「好使的运维系统」。
当然, 一般企业不会专门为运维开发配备「产品经理」,所以运维开发想要再往高级发展的话,也可以替代运维出需求,升级为运维产品经理,以程序员的思维角度来解决运维服务的工程效率和质量问题,我认为这也是类似 Google 所提倡的 SRE 文化。

运维开发首先是一个程序员,不是运维工程师。
一个好的运维开发需要具备 「运维理解」+「开发能力」:

对「开发能力」的技术要求低于其他业务形态(如游戏、电商、搜索等)。
对运维业务的理解难度会低于电商、游戏等业务形态,即对「运维理解」的要求不高。
对运维相关技术栈的掌握程度要求高,如Python/PHP/Go/Shell、 Linux、Git、Nginx、Zabbix、Docker、K8S等。