问题描述
在我目前的工作中，我最初是一名软件开发人员，然后逐渐过渡到了一个DEVOPS职位。我担心会被解雇，不是因为我做错了什么，而是因为我习惯了主动做事情（编写代码），而我现在大部分的时间都是坐在那里等待事情发生…。我每天的职责（我已经在一封详细的电子邮件中向我的经理列出了这些内容）包括：
- 监控5个不同服务器的性能。
- 监控其中2个服务器上的Active Batch执行代理。
- 处理创建的请求。
- 处理创建的项目任务。
- 监控电子邮件/Skype/电话。
- 构建任何不直接通过工单系统指派的请求。
乍一看，这似乎很多，但实际上所涉及的工作不过是在一个监视器上查看新错误，另一个监视器上查看消息。我通常可以在几分钟到1小时内完成工单。这对于DevOps来说正常吗？如果是这样，我该怎么做才能更有用？如果不是，我是否面临被解雇的危险？
解决方案
以下是一些可能的解决方案，根据你的公司情况可能会有所不同。
了解目标
首先，你需要清楚地了解服务水平目标。外部客户实际关心什么？如果他们不关心正常运行时间，就不要把正常运行时间的衡量放在高优先级。也许延迟、软件更新、内容准确性或其他某些指标更为重要。同时，也要了解内部客户的需求（你的老板、同事等）。他们关心什么事情？
一旦你了解了客户最关心的事情，就要开始测量、测量、再测量！尽可能多地收集有关那些重要事项的数据。部署代码需要多长时间？当你关闭工单时，有多少百分比的时间工单会无法解决？等等。利用这些测量结果来不断改进。
以下是你可以集中精力的一些领域（根据所在公司可能会有所不同）：
配置
如果有人登录服务器并破坏了配置，纠正错误会有多困难？
- 你应该能够轻松地构建和替换资源。
- 配置管理应该完备，以便跟踪所有有意义的更改。
- 最理想的情况是，根据需要构建流程或工具，以便开发人员可以在受控且协作的方式下修改配置（DevOps！）。
CI/CD
当发布新代码时，它是如何交付的？
- 当代码推送到源代码库时，应触发自动化测试和部署。如果可能的话，这应该在一个流水线中进行，顺序部署多个环境，以确保测试通过（开发 -> 测试 -> 用户验收测试 -> 生产）。
- 提高可见性，以便您可以轻松查看不同版本的代码在哪些环境中运行，出现了什么错误以及性能如何变化。
- 使软件开发人员能够自行交付代码（DevOps！）。
- 与开发人员合作，改进这个过程（DevOps！）。
日志/指标
当出现问题时，您能多快地找出问题所在？如果两个月前出现问题，您还能找出问题所在吗？
- 在一个中心位置收集日志，使用能帮助您搜索和可视化的工具。
- 使用能帮助可视化的工具汇总指标。
- 减少噪音！如果它没有意义，就不要保留它（但要稍微保守，有时事情后来可能变得有意义）。
- 与开发人员合作，了解日志和指标如何帮助他们交付更好的软件（DevOps！）。
警报/事故响应
理想情况下，除非出现实际问题需要解决，否则您不应该看图、仪表板或日志消息。坐着观看仪表板不是人类的好任务。
- 设置警报，以便在问题出现时得到通知。
- 警报应该发送给一个人，就是正确的人。
- 警报应该是紧急的（需要立即处理），并且是可操作的（接收警报的人可以解决问题）。
- 考虑将开发人员加入一种值班轮班制（甚至只是周一到周五的8点到17点，处理一些代码问题）（DevOps？）。
灾难恢复
如果您的服务器今天被摧毁，重新运行需要多长时间？
- 备份数据并设置备份基础设施。
- 定期测试备份恢复。
- 定期测试到备份基础设施的切换。
- 与开发人员合作，更好地了解代码在故障转移场景中的操作方式，并根据需要进行改进（DevOps！）。
文档
万一发生了什么事情，你的工作不幸遭遇意外，其他人有多大
正文完