erp技术开发/应用/实施_开发/运营文化的观察

erp技术开发/应用/实施

我现在将永远是领导力和设计专业的学生。 我喜欢看到事物有效，但是当事物的工作原理比过去更好或略有不同时，我会更喜欢它。 我最喜欢改变，当目标是学习和改进时，我将其视为进步。 当一切运行良好时，我想知道它们是否可以更好地工作，反正我最终还是与他们修补。 我不喜欢“如果没有解决就不要修复”这一口头禅，因为我认为大多数事情都可以改进，有些人只是不知道怎么做。

我现在已经为3家SaaS公司工作，而所有3家公司对我今天对运营与工程的看法都产生了有意义的影响。 有时我学习有效的方法，有时我学习无效的方法，但是我总是学习。 不过，在我所学到的所有知识中，我正在将文化（即工作场所难以形容，不言而喻的法律）视为公司最有意义的衡量标准，也是定义错误判断是否确实有助于经验和经验的衡量标准。反过来，好的判断力。

对于某些人来说，文化是一件轻率的事情，公司会用昂贵的聚会，昂贵的计算机，自来水上的啤酒，踏板车从大厅飞来飞去，等等。 公司这样做是希望通过投资来吸引顶尖人才。 但是对我而言，文化与那些东西无关。 文化使客户支持中的某人成为CTO。 文化是允许谈论或改变错误决定的原因。 文化可以使员工在公司工作多年，或者使他们每2-3个工作机会增加一次。 文化是公司运营且无法制造的方式的现实。

这是一篇很长的文章–如果您只想得出我的结论，可以跳到底部。

公司A
2006年，科技公司才刚刚从点炸弹崩溃中恢复过来。 大多数公司都处于困境，虽然找到系统管理员的工作并不难，但公司正在寻找经验。 在此期间，“ A”是一个异常。 他们已经获得了无数资金，并准备接管移动视频的世界。 他们想要摇滚明星，而且他们想要很多-因为他们需要他们。

通过建立前台来聘用“ A”人员-他们有很多钱，没有其他人可以享受的服务，以及一群真正聪明的人，他们想做点新的事-视频到移动。 他们的文化“快速发展”，仅此而已。 “ A”在多个月的发布周期内构建和部署了软件，而每次发布时，都是一团糟。 他们将尽可能多地塞入每个发行版中，在与生产不相似的环境中进行测试，然后从某个晚上晚上10点开始–我们将进行部署。 6-8小时后，当太阳开始升起时，我们都会回家……真糟。

当出现生产问题时，Ops首先解决问题。 如果是有人在那儿呆了一段时间，他们有时可以处理它-但在很大程度上，开发人员必须介入，这有时可能是一个漫长的过程。 在“ A”，数小时的停电很常见。
在“ A”上度过的3.5年里，我看到了无数不可行的例子：

• 在较长的发布周期内交付基于服务的应用程序是行不通的，因为在开发软件时需求实际上会发生变化。 坏了
• 开发人员在不了解生产方式的情况下设计新应用程序是行不通的。 他们失败了。
• 依靠拥有一流的Ops团队成员来保持您的服务不起作用。 他们不能。
• 添加更多的机器而不是投资于工程上的工作是行不通的。 费用加起来。
• 记录更改以防止做出错误决定是行不通的。 只是没有。

随着时间的流逝，人们开始意识到这些事情是错误的，但是转向这艘船就像在导航泰坦尼克号。 “ A”发展了分析瘫痪的文化。 由于发布和生产变更非​​常差，因此需要更多的“控制” –更加严格和更多的过程。 将变更投入生产比较困难，而不是容易。 每个生产变更都必须有相关的文件-这些文件需要批准。 我负责将其中的一些放置到位，并且我再也不会做。 该公司开始专注于在您所做的所有事情中建立可否认性，这是一种CYA文化。 它也可能被绑在树上，挂在树上–它无法移动。

最终，他们成立了一个独立的组织，称为“ CTO办公室”，可以在其中做出设计决策，工程师可以在其中独立研究新想法。 该组织提出的设计很少达到目标。 团队有出色的成员，但与日常运营的现实隔绝。 当他们遇到生产问题并不得不快速解决问题时，他们提供了巨大的帮助，他们很少有紧迫的竞争期限，而且他们是一流的工程师。 但是，当从头开始设计某些东西时，这很困难。

我学到了什么？

变更控制做错了可能会很糟糕。 漫长的发布周期和爆炸式的发布很糟糕。 开发人员不知道生产的工作方式是不好的。 不知道生产方式的测试人员会更糟。 依靠操作来补偿代码和设计质量将失败。 隔离构建新组件的工程师注定会失败。 金钱并不能带来幸福或良好的文化。

公司“ B”
在寻找下一个职位时，我想要相反的事情–我想要自由，而我在“ B”找到了它。 该公司规模很小，大约有30名员工，发布周期为6周。 办公室的墙上贴着海报：“要好，要有条理，要有创造力”，这似乎是事情的运作方式。 “ B”具有与“ A”截然不同的问题。 在“ B”开发人员非常了解生产的工作方式，通常比Ops更重要。 开发人员具有生产访问权限，并且当生产中出现问题时（这比公司“ A”少得多），开发人员正在与Ops一起查看。

“ B”的问题最初在很大程度上是可操作的。 监控范围实际上比“ A”公司要好得多，但是监控是如此嘈杂，您无法分辨出什么是好是坏。 磁盘将填满，因为日志未正确旋转。 服务将消失，并且存在手动流程来恢复它们。 磁盘在其大型存储服务中几乎每天都会发生故障，并且与时俱进是一项全职工作。 运营部门将所有时间都花在剃毛ks牛身上，从来没有任何时间使事情变得更好。

“ B”公司做得相当不错的一件事是配置管理和自动化部署。 总体而言，大多数事情是通过puppet或我们的部署脚本来管理的。 如果发生中断，我们可以在10到15分钟内将其部署到整个系统（> 150个系统）。 滚动发布更让人痛苦，但肯定很常见，而且大多是自动化的。

与“ A”公司一样，“ B”公司大力推动快速发展，发布功能，赢得客户。 尽管开发人员似乎将大量时间集中在构建功能上，但他们也确实为某些事情确定了基础结构修复的优先级。 随着时间的流逝，这种情况会发生变化，但是起初看起来还不错。 服务运行得很好，并且一切都保持稳定。

随着时间的流逝，我注意到“ B”公司的窗户很多。 日志中充满了异常，您无法分辨什么是“正常错误”以及什么是错误的。 几乎每个应用程序都在重启脚本下运行，笨拙的perl脚本会在该应用程序死后重新启动并发送电子邮件以提醒人们。 通常，我们最早表明服务存在问题的指标是应用程序崩溃的频率。 很难知道服务是否正常运行，并且当您知道有一项服务时很难查明问题。 随着每个发行版的发布，他们的技术债务越来越大，而运营部门则将大部分时间都花在了中断/修复方面，而不是长期的改进上。
“ B”公司的订户增长速度也非常快，并且没有像获得客户那样快地优化他们的软件。 足够快地配置硬件成为一个实际问题，并且跟上数据库分片和存储增长的步伐也是一个大问题。 他们正在尝试，但仍将重点放在新功能上并增加客户。

如果仅允许资金和想要功能，则“ B”公司的文化将允许有一个枢纽来解决这些问题。 可以说，他们的产品具有比市场上任何其他产品都更多的功能，并且他们继续增加更多的功能。 他们着迷于构建其他所有人拥有的东西，甚至更多。 但是，它们仍然不是第一名，还有其他竞争对手根据订阅人数和对市场的熟悉程度击败了他们。 我必须通过询问人们是否听说过我们的竞争对手来向他们解释我的公司做了什么。 我会说：“我们做他们做的事”。 我总是很always脚。

我学到了什么？

配置管理和部署自动化非常棒-在这里，我决定这些是关键功能。 “破窗综合症”是真实的，对组织解决问题的能力产生了巨大影响。 优先考虑基础设施修复和减少技术债务与意识到问题同等重要。 开发人员对*生产中*的代码功能的所有权至关重要-如果知道它在测试中不起作用，则知道它在测试中是无关紧要的。 监控，趋势和分析是了解您的系统在做什么以及许多公司错过的机会的基础。

公司“ C”
我仅在“ C”公司呆了5个月，但是我被带到了学校。 当我外出寻找“ B”公司之后的东西时，我正在寻找一个了解运营服务含义的地方–在这个地方，我可以不再打扰连续交付的钟声，而去从事实际的业务。 虽然这家公司并不完美，但我相信几年后我会学到更多东西，但到目前为止，我所观察到的一切改变了我对许多事情的看法。
公司“ C”具有一些关键的文化方面的特征，使其成为“ C”公司：

• 决策是通过结构化的协作和共识来驱动的。 个人有做出决定的能力，但是有着强烈的共享，协作和调整的文化。
• 鼓励个人在公司中找到自己的位置。 您被任命为公司中一个松散定义的职位，并且期望您会继续担任该职位，直到其他人担任该职位为止，但是我们鼓励您发掘自己的热情并将精力投入公司的那个领域。
• 公司的领导者可以帮助支持团队决策。 像任何公司一样，管理层也有一些指导，但通常都是通过共享和协作的方式来完成的。
• 他们非常注重个性适合的招聘，而不是技术技能。

这种核心文化使公司成为现实，并导致了对问题的一些有趣的回应。 当服务开始崩溃并遇到严重的可用性问题时，他们成立了一个架构委员会，这是一群对服务的构建方式充满热情的个人。 该组包括工程，运营和产品成员（总共约20人）。 服务的任何重大更改都会在构建之前提交给该小组并进行讨论。 需要对该体系结构进行更改的主要问题被提出来，进行了讨论并确定了优先级。

像该公司的其他事情一样，该小组可能是通过发送电子邮件询问那些热衷于修复这些问题的志愿者而组成的。

该公司要做的另一件事是根据数据做出决策。 他们有不少于3个人完全专注于基础架构以及测试和生产指标的分析。 这包括负载测试和性能测试环境。 记录生产和测试中每个请求的指标。 详细分析，包括对系统的每个请求的数据库时间，CPU时间，堆空间等。 如果发生断电，该小组通常可以指出受影响的人数和他们是谁。 如果客户的行为不正常，他们通常可以快速找到它们。 如果存在性能问题，他们可以非常准确地描述它们，通常将这些问题与特定提交相关联。 这使围绕性能调优的对话变得更加容易。

我观察到一种一致的策略来尝试某些事情，并在它们不起作用时愿意对其进行更改。 许多公司尝试新事物，认为如果不工作就可以进行更改，但是很少有公司拥有结构化的流程来确保发生更改。 这家公司做。 它需要纪律。

并非偶然的是，该公司还与客户分享他们的经验，并利用自己的组织作为新想法的试验场。
所有这些的结果–尽管拥有我曾经为他们服务过的公司中最小的基础架构：

• 对于每个出现的新功能，甚至对于现有功能的更改，都使用功能标志。
• 每周发布，是上述公司中最快的步伐。
• 具有全自动和无人值守（计划的）部署。
• 在我工作过的公司中拥有最高的可用性。

我在学什么？
我正在学习，让人们去做自己的工作比告诉他们如何做和让他们随心所欲产生的结果更有价值。 正确完成这项合作可能会非常有价值，并且尽管它不允许摇滚明星照耀自己的光芒，但它会产生更加一致的结果，并且总体上会产生更积极的效果。 我了解到我所服务的公司做错了协作，而做正确的事需要纪律和培训。 我了解到，建立一种良好的文化与公司的领导力有关系，而与产品或资金的关系则很小。

那么，这意味着什么？
我已经相信每个公司都有熟练的团队成员。 每个公司在发展业务和扩展系统方面都面临挑战。 每个公司都提出解决问题的聪明方法。 我所工作的公司与众不同之处是，有些人了解他们无法了解所有事情，并建立了结构化的流程来确保随着新事物的学习而发生变化。 其他人似乎相信变革将有机地发生–重要的问题如果足够重要就将得到解决。 但是，这不会发生，因为该业务不允许团队选择对那些重要的事情进行优先级排序。 他们不允许拥有所有权。

我还观察到，每次机会都需要抵制和质疑添加过程。 当流程使决策更好，使组织更有效时，流程才是好的。 当过程阻碍效率，扼杀敏捷性以及导致人们因工作量过多而无法做出正确的决定时，过程就是不好的。

我了解到破损的窗户综合征是真实的，在技术公司中，要保持这些窗户固定需要花费大量的工作。 知道什么时候问题是真实的而不是“正常问题”很重要。 如果某事不够重要以至于无法正确构建，那么也许一开始它就不够重要。 将破损的窗户留在原处意味着您可以选择质量较低的产品，并且导条只会向下方移动-永远不会向上方移动。

我见过的避免这些问题的最棒的工具是让个人有权组织团队并采取行动。 鼓励他们进行协作，并为团队创造机会，让他们在一起并分享经验。 回顾是非常好的。 让运营部门参加工程会议，让工程师参加运营会议。 让每个人都分享他们的经验-好与坏。 您将花费大量时间参加会议，这会降低效率，因为它确实如此。 效率是以效率为代价的。 当您采取行动时，您会更好地知道为什么要这样做以及预期的结果是什么。
如果您做的不好，效率没有多大意义。 更快地处理破碎的东西是没有意义的。

最后，我了解到吉姆·柯林斯（Jim Collins）的《从善到善 》是正确的。 期。

参考： JCG合作伙伴 对Dev / Ops文化的观察   Aaron Nichols在Operation Bootstrap博客上。

翻译自: https://www.javacodegeeks.com/2012/03/observations-on-dev-ops-culture.html

erp技术开发/应用/实施