golang的运维开发

运维开发工程师（ 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等。