大家好！我叫Timur Gilmullin，是Positive Technologies技术和开发流程部门的副主管，我从事自动化工作，并实现DevOps的思想。今天，我将告诉您我如何进入该行业，在我们部门中如何看待DevOps工程师的职业，胜任力图以及如何帮助确保员工成长。免责声明
本文并非试图描述DevOps工程师的理想职业道路。我们的目标是分享经验，并告诉他们如何与我们合作。有专门的公司（express 42，flant）和社区（devops deflope）为俄罗斯DevOps创意的发展做出了重要贡献，我们选择了一系列适合我们的技术。关于我们如何在部门和公司中开发DevOps创意，您可以在Habré上阅读：现在，走吧！为什么我们需要DevOps
每个公司都有自己的自动化部门详细信息。通常，在几个独立部门级别上难以执行或过于昂贵的任务将转移到集中式组或自动化部门。在我们公司中，实施DevOps构想的全球目标是确保从数量上（工时或机时，CPU，RAM）定量降低生产成本和产品支持。基于此目标，强调了自动化部门在整个公司级别的作用 -这是为了最大程度地减少在生产的各个阶段执行典型的串行任务的成本。怎么运行的
自动化部门的职能职责也高度依赖于特定公司的具体情况。我们公司是信息安全解决方案的开发商和供应商，自动化部门负责生产输送机-从组装产品的各个组件到将其发送以进行测试并将更新交付给客户的基础架构。我们帮助团队中的主要开发流程实现自动化，并确保我们系统的性能（持续集成和持续交付（CI / CD））。我们的工作分为几个职能领域。持续集成的方向支持开发人员和测试人员的组装和测试管道。基础架构的方向涉及部门所有“铁”资源的使用和操作的优化，以及虚拟机及其环境的部署（基础架构作为代码）的自动化。监控方向可控制服务的每日可用性。我们还为开发人员提供监视即服务（监视即服务）。工作流方向为团队提供了用于管理开发和测试过程，分析代码状态并获得项目分析的工具。最后，webdev在公司更新服务器（GUS和FLUS）上提供发布版本，并使用许可实验室服务提供许可产品。为了支持生产管道，我们为开发人员设置并维护了许多不同的支持服务。关于其中一些的故事可以在我们的旧手套上听到：Op！DevOps！2016和Op！DevOps！2017。我们还开发了内部自动化工具，包括DevOpsHQ。
我们工程师的经验
我们自动化部门的人员（为简单起见，非正式地称为DevOps部门）的背景完全不同：曾经有测试人员，程序员，工程师和IT管理员。我是数学和计算机科学专业的文凭老师。事实证明，由于经验的多样性，我们能够应付我们所有领域的任务。我们部门中没有一个工程师可以一手解决所有领域的所有问题。但是，作为行政单位，我们一起成为SRE（不是站点，而是服务可靠性工程师，因为我们为开发人员提供服务支持），这是一名工程师的人力资源专家未能成功找到的。我们相信，只有作为一个多元化工程师团队的一部分，才能解决公司各种各样的产品任务。我们有很多实现自动化的技术案例。但是最主要的是向人们解释为什么他们需要这种自动化。最简单的方法是技术任务来自业务，也就是说，当把钱带到公司的人有清楚的了解：什么，如何以及何时进行或优化。我建议您看一下我们的自动化案例：“ 个人经验：我们的持续集成系统是什么样的。”关于我们的DevOps部门的职业
我想说的是一切都已经准备好并事先计划了，但事实并非如此。最初，我们的增长和发展计划中没有任何内容。 2014年，当我移居技术和开发流程部门时，产品开发始终秉承初创公司的精神：现在和现在都需要做所有事情，长期计划没有被接受，其中有很多“遗产”。当时只有四名工程师，我们还有许多技术任务：我们迫切需要进行CI，扩展装配线，在此之前，当然要创建此生产线，并与内部客户（开发部门的程序员）建立互动。但是，随着时间的流逝，流程不断改善，部门不断壮大。和他在一起，人们对我们的工程师想知道的东西有了越来越多的了解：他们作为专家的发展前景如何，部门可以为新工程师提供什么？从逻辑上讲的第一件事是，我们将需要一个用于工程师职位和类别的增长表。俗话说：社会没有裤子的颜色差异，那就没有目的！当没有目标时...我们使一切尽可能简单。我们部门的内部组织结构由三个领导职位（部门负责人，副领导和小组负责人）和四个执行职位（初级，常规，高级和首席软件工程师）组成，每个职位又分为三类。人力资源部门通常使用类似的职务，但没有划分类别。对于我们部门而言，随着员工职责范围和工作量的增加，这些类别有助于确保员工更平稳，逐步地增长。
对于每个类别，我们都编写了带有职务说明的文档，其中规定了员工的职能和角色，并指出了员工在服务方面的责任领域和工作领域。但是由于我们除了工程学之外，还喜欢编程，而且我们都不喜欢阅读无聊的文档，因此我们在这里也简化了我们的生活。我们并不是用Word编写每条指令，而是以纯文本的形式编写，并以特殊的Markdown标记语言格式化。同时，任何编辑人员的可读性都不会丢失。之后，我们将这些文本保存在GitLab存储库中。 GitLab本身可以非常漂亮地显示各种文档格式，包括Markdown绘图，因此无法与Word区别开来。并且标准的Git客户端具有许多其他功能，例如，它可以显示两个文档之间的差异。这极大地简化了工程师的工作，他想找出他需要遵循的正式要求，以便进入我们部门个人发展的下一步（类别）。要找出两个职位描述的正式要求之间的区别，您需要执行一些简单的步骤：从我们的GitLab下载带有职位描述的存储库，查找文档，在控制台中执行Git命令以显示两个文件的比较。例如，您可以看到第二级和第一级高级工程师之间的区别如下：git --no-pager diff --no-index
level_08__DevOps_Senior_Software_Engineer_2nd_category.md
level_09__DevOps_Senior_Software_Engineer_1st_category.md
在所有软件工程师都习惯的控制台中，负号和红色代表已更改或已删除的要求，而添加的行则带有加号和绿色而突出：每行是一个新要求。是的，我们有点技术狂，但是对我们来说，这似乎是一个不错的解决方案：
DevOps工程师能力图
随着我们部门的发展以及我们所支持的产品输送机数量的增加，我们意识到对于我们所从事的每个工作领域，不可能描述独特的角色并在市场上找到合适的工程师。我们有自己的工作细节，例如，我们不需要大型技能的程序员软件开发人员来解决CI问题，但是，CI工程师必须能够以可接受的水平用Python编写小型模块和脚本。同样，我们不需要超级合格的Linux管理员，但是我们需要一个对Debian或Ubuntu OS有足够了解的人，以便他可以安装GitLab CI构建代理，甚至更好地通过SaltStack，Ansible或其他工具自动化这些工作。那么，在我们部门工作的DevOps工程师应该怎么做？为此，您首先需要确定一般意义上的知识，技能和能力（简称ZUN）。- 知识是学科领域的主要定律，使人们能够解决特定的生产，科学和其他问题，即事实，概念，判断，图像，关系，估计，规则，算法，启发法以及该领域的决策策略。知识也是彼此之间以及与外界联系的信息元素。
- 技能 -具有一定知识知识的人将其理解为由他们掌握如何执行动作的技能。这种能力表示为在实践中有意识地应用知识的能力。
- — , . , , , , .
如果我们根据公司开发的产品更具体地定义ZUN，那么我们将获得一般能力列表。如果不掌握这些能力，工程师将无法在我们部门进行定性工作。清单很长，因为它立即考虑了所有领域，技术和产品的工作细节。因此，我们迫切需要以表格形式描述和分类对工程师的所有要求，并且我们有一个“ DevOps Engineers 1.0能力地图 ”。看起来像这样：该
表分为四个大部分：
- 成功解决日常任务所必需的DevOps部门员工的一般能力描述。
- 知识是DevOps工程师的特定的，面向产品的知识。
- — ; .
- — ; , .
在表格的单元格中，进行了定性评估：工程师应在大约什么水平上具备一项或多项能力。不幸的是，我无法想象这里有完整的表格，但这不是必须的，因为每个公司和每个部门都必须创建自己的相似表格，并考虑到工作的细节。在2018年，我和我的同事们开发并创建了所谓的生产过程技术图（请阅读Habr上的文章“ 混乱的管理：我们使用技术图将事物按顺序排列 ”）。多亏了她，我们几乎可以根据产品，产品中使用的技术以及产品传送带的阶段来创建DevOps工程师的能力成长和发展的载体。
这样的地图描述了构成我们产品生产的技术传送带的所有阶段和步骤。从产品的角度来看，主要的事情是要了解确保该输送机连续运行所需的工程师数量，资格和能力。更好的是，对人员进行计划和保护，以便尽管有关键服务的支持，但他们仍可以例如平静地休假，因为他们知道部门中有人可以交叉胜任并且可以代替他们。总之，这将使我们进入“ DevOps Engineers 2.0能力地图”，该地图将清楚地描述ZUN，具体取决于产品和该产品自动化工作所需的能力。也就是说，应该将技术图上的各个阶段与工程师的能力图结合起来。在下一篇文章中，我将尝试告诉您其中的内容。PS：本文是根据1月份会议的故事撰写的，Hays的同事恳请我们交流经验（您可以查看演示文稿和文本）。作者：Timur Gilmullin-副 积极技术技术与开发流程（DevOps）负责人。