敏捷系统管理员和 DevOps - 如何实现?

敏捷系统管理员和 DevOps - 如何实现?

如今,敏捷系统管理和 DevOps 是系统管理和运营方面最热门的话题之一。这两个概念主要侧重于弥合运营/系统管理员与项目之间的差距(开发人员、企业等)。即使您从未听说过 DevOps 概念,我相信这个话题也是您关心的。

那么,您在公司中使用什么工具和技术来实现 DevOps?我对变更管理、持续集成和自动化等主题特别感兴趣,但不仅仅是这些主题。请分享您的想法。我期待阅读您的答案/意见 :)

答案1

  • svn/git——显然是修订控制。

  • trac/redmine/jira-票务。

  • cobbler - 用于基本操作系统服务器配置。Cobbler 是一款专注于 redhat 系列的产品,但我确信 debian/ubuntu 也有类似的产品。同样,大多数“云控制面板”公司(如 RightScale)都会为您提供此功能。这里的口号是“JEOS”或“刚好足够的操作系统”。我的路线是使用 kickstart 中的“%packages --nobase”行,然后通过以下方式构建我的特定堆栈...

  • puppet/chef - 用于配置管理和一致性实施。这里还有其他选项,使用哪个选项比使用哪个选项更重要。我发现一个特别重要的技巧是将配置存储在与开发人员使用的相同版本控制系统中。这有助于整合两个团队的工作流程并使其彼此可见。

  • func(或 capistrano 或 cluster-ssh)- 用于在集群中运行部署脚本。这里的诀窍是让高级开发人员可以自己运行它,以便将新事物推送到线上并推送不可避免的修复。
    这实际上是 devops 的核心,使开发人员能够破坏和修复环境。许多系统管理员太贪得无厌,无法像这样放手,或者他们的管理层仍然坚持系统管理员应该监督开发人员的错误观念(好像我们甚至可以读懂他们正在做的事情的一半)。

  • cacti/ganglia/collectd/munin - 图表非常关键。它结合了指标的商业价值和简单视觉效果的人文价值。将代码推送的时间戳与图表中更改的时间戳相关联,对于解决性能回归问题和了解性能决策的真实情况非常有价值。这里的关键点是图表需要易于开发人员查看和使用,他们的管理层需要对他们有这样的期望。

  • nagios/zabbix/smokeping/etc - 监控服务器内容和“基本页面”类型的性能指标。图表再次成为关键。这些更适合团队的运营方面。

  • gomez/keynote/browsermob - 对整个浏览器性能进行外部监控,同时考虑第三方服务、CDN 和渲染时间问题。这些功能更适合团队的开发方面。

这是工具和技术的混合,重点是技术。特别是 DevOps 的“系统管理员”思维方式从“管理”转变为“操作”。这是关于赋能开发人员。使他们能够做事,使他们能够修复问题,使他们能够看到他们所做事情的真实事实/指标/图表。相反,开发人员需要接受他们已被赋能的事实,并实际进行观察性能趋势、调试问题的工作,不仅要考虑功能,还要考虑如何推出它们以及它们将如何影响整个系统/环境的健康状况。

答案2

我们正在 National Instruments 上做这件事。您可以在以下网址阅读更多关于我们正在做的事情http://dev2ops.org/blog/2010/4/27/qa-ernest-mueller-on-bringing-agile-to-operations.html

Cagenut 在这里提到的工具组合基本上与我们在这里前进的方向一致。

答案3

最好的方法是了解你的工作环境。首先与开发人员和经理交谈。尝试让他们参与进来并与他们交流想法。他们很可能对事情的运作方式有很好的想法,并且知道你引入 DevOps 的想法是否会引起任何问题。

从那里开始查看应用程序并逐个介绍它们以解决问题。

答案4

虽然工具和技术很重要,但关键路径是整个组织的协作。如今,IT 运营业务运营。Etsy 在其仪表板上显示收入变化,每个人都可以看到。

相关内容