开发人员 生产环境账号
Devops中的基本思想之一是，开发人员和运营人员应共同承担系统设计，实施和保持系统运行的责任。 如果出现问题，开发人员应随时待命，并应解决任何问题。 因为编写代码的人通常是唯一知道代码如何工作的人。 而且由于存在道德风险论证：如果让程序员对他们所做的工作负全部责任，那么他们就会被激励去做更好的工作，而不是写垃圾并将其交给其他人。
但这意味着开发人员需要某种访问生产的权限 。 开发人员需要多少访问权限 ， 多长时间访问一次以及如何使其安全，这是必须回答的重要问题。
雇用邪恶的聪明人，并赋予他们所有人访问root的权限。
未命名的devop传播者， Devops是否具有颠覆性？
如果您问开发人员是否应有权使用产品，您会发现人们属于以下三个阵营之一：
是的，当然可以，还有谁将支持该系统？
对于在线初创公司来说 ，这是一个简单的决定 ，因为那里通常没有其他人以任何方式来安装，配置和支持该应用程序。
随着这些组织的发展， 开发人员通常会继续密切参与部署 ，支持和应用程序操作，在某些情况下，它们仍然扮演主要角色，尤其是在大量利用云基础架构的商店中（例如Netflix ）。
你疯了吗？
问题：开发人员应该可以使用生产吗？
答：不仅不行，地狱不行。
kperrier， Slashdot：开发人员应该可以使用生产吗
在大型企业和政府组织中，情况有很大不同，由于各种不同的原因，开发和运营之间已建立起隔离墙。 做到这一点的不仅是并购，惯性，内部政治和保护主义。 它还是SOX和PCI ，HIPAA和GLBA以及其他重叠的法规和隐私规则，以及ITIL和COBIT以及ISOxxx和CMMI和其他IT治理框架，以及内部和外部审计员按顺序划分职责和需要知道的访问限制确保系统数据的完整性和机密性。
相同的规则也适用于精简的Devops商店。 例如，在Etsy的（一个DevOps的领导者）， PCI DSS合规职能的管理和支持 ，从他们的在线系统的其余部分以不同的方式由不同的团队：而研发人员也来了很多生产的R / O访问“ 数据色情 ”（ 指标，图形和日志），则他们无权访问生产数据库； 活动记录还有更多要求； 进行质量检查的方法与处理生产的方法明显不同； 所有生产变更必须通过票务系统进行跟踪和批准。
还有共享基础架构的问题：许多不同的应用程序和不同的业务部门可能使用相同的网络，服务器，数据库以及堆栈的其他部分。 当然，开发人员仅了解他们正在使用的应用程序，并且仅熟悉他们日常使用的简化测试配置–他们可能不了解其他系统及其共享的依存关系，并且很容易进行更改以破坏这些系统系统没有意识到风险。
紧急情况下，请打破玻璃
大多数组织都处于介于云中的Noops Web初创企业和受过多治理和管理政策束缚的传统企业之间。 运营通常是独立运行的，管理仍然要对监管者和审计师负责，但是大多数人理解并认识到开发人员需要帮助的必要，尤其是出现问题时。
当这种情况确实确实发生时，开发人员（通常通常只有高级开发人员或团队负责人）被带进来，以帮助进行故障排除和恢复。 他们的访问是临时的，可能使用从库中提取的“ fire id ”，然后在完成后立即将其锁定。 开发人员通常与负责大部分驾驶工作的操作伙伴配对，或者至少在开发人员必须开车时仔细观察他们。
问题：开发人员应该可以使用生产吗？
答：每个人都同意开发人员永远都不能访问生产…除非他们是开发人员，在这种情况下情况有所不同。
SatanicPuppy， Slashdot：开发人员应该可以使用生产吗
如果开发人员可以查看日志，堆栈跟踪和核心转储，并在出现问题时查看生产数据，则可以更快地解决生产中的问题。 至少让一些开发人员可以读取生产日志，警报和监视器，从而足以识别出问题并找出需要修复的内容。
有时，确实发生了非常糟糕的事情，而最重要的是使系统尽快恢复正常运行。 您需要可以找到解决该问题的最佳人才，其中包括开发人员。 您将需要他们的帮助进行诊断，并确定最安全的方法是回滚或前滚，进行紧急修复或变通以及数据修复和对帐。 每个人都需要稍后检查，以确保正确实施了所有临时修复程序或变通办法，并已检入并重新部署。
在运行事件管理防火练习时 ，请确保包括开发人员。 而且，即使开发人员不属于事件管理团队，也应该将其包括在事件事后评估中 ，因为这是一次了解系统并进行改进的重要机会。 但是，如果您让开发人员在生产中进行消防工作比几乎没有，那么您所做的几乎都是错误的事情。
在生产中进行调试？
有些问题，间歇性故障以及与计时相关的问题和heisenbug ，仅发生在生产中，无法在测试中重现-或至少没有很多时间，金钱和运气。 要调试这些问题，开发人员可能需要在问题发生时检查系统的运行时状态。 但是这些问题应该是例外，而不是常规。 生产中的调试带来了安全性问题 （将私有数据暴露在内存中）以及开发人员和Ops都需要意识到的运行时风险。
问题：开发人员应该可以使用生产吗？
答：每当发生无法在开发环境中复制的错误时，我总是很想跳入prod并开始添加一些输出语句…是的，我可能无法使用prod可能是一件好事。
Enderjsy， Slashdot：开发人员应该可以使用生产吗
部署到生产？
审核员会告诉您，编写代码的人员不能与在生产环境中部署代码的人员相同。 但是有些开发人员会告诉您，他们需要注意部署，因为Ops无法理解所有涉及的步骤，或者至少他们需要手动检查所有配置更改是否正确进行并运行数据。转换并检查它是否有效，并确保在正确的位置安装了正确的代码。 如果这是完成部署的方式，那么您做错了。
如果Ops不信任开发以至于根本无法做出更改，那么您做错了很多事情：
多数情况下，当我看到开发人员陷入生产困境时，要么是“英雄”编码员太过优秀而无法使用最佳实践，要么是环境如此恶劣以至于“最佳”解决方案似乎违反了规则。
我曾经为一家公司做过一些合同工作，该公司的质量保证和测试过程至少花了两周的时间才能完成最琐碎的更改，并且生产服务器的管理员拒绝部署安全补丁之类的产品，而测试时间却接近一个月。 那里的开发人员有一百个技巧，可以将他们的代码潜入生产环境，并将生产代码链接到开发服务器，以实现他们的生产力目标。
SatanicPuppy， Slashdot：开发人员应该可以使用生产吗
在生产中进行测试？
生产中唯一必须进行的测试是A / B拆分测试，以了解客户喜欢或不喜欢的功能。 您可能不需要在生产中进行测试以查看是否有某些功能（即测试环境适用的功能），除非您是首次部署和启动系统，或者与其他系统的某些有限集成测试用例无法结合使用从测试环境到达。 还是使用Ops进行负载测试–许多商店负担不起足以进行实际负载测试的测试环境。
使开发人员（或从开发人员）安全生产
开发人员是否应该具有生产访问权限（以及您可以允许他们进行多少访问），还取决于可以信任多少开发人员对系统和客户数据进行谨慎和负责。 不一致的是，尽管组织将信任开发人员来编写可在生产环境中运行的软件，但他们不会将其与生产系统相信任。 但是发展和生产是不同的世界。
大多数开发人员缺乏必要的情境意识。 他们习惯于尝试并尝试观察事情的发展。 我已经看到聪明，有经验的开发人员在深入解决问题时会在生产中做危险的事情而没有意识到。 开发人员应该害怕在生产中工作。 不必太害怕思考，但要在他们采取行动之前就足够害怕思考。 他们需要了解风险，并与Ops中的任何人一样承担同样的护理职责。
您可能会花费大量时间来破坏开发和运营之间的隔wall，只是看到它在一夜之间（又是开发者越来越厚）重新构建起来，这是开发人员在第一次以测试为目的销毁生产数据库时，或杀死错误的进程或热部署错误版本的代码或删除错误的配置文件并导致广泛的故障 。 确保测试和开发环境从生产环境进入防火墙，以便测试中运行的任何东西都不可能通过硬连线链接接触生产环境。 在开发人员生产时向他们明确说明。 强迫他们跳：打开隧道，使用不同的ID和密码登录，并看到不同的提示。
拥有权利的同时也被赋予了重大的责任
支持应用程序的任何人都不需要（甚至不需要）root访问权限来获得日常支持和故障排除。 开发人员应仅被授予他们所需的访问权限，而不再获得更多访问权限 ，以使他们无法做自己不应该做的事情，不能看到自己不应该看到的事情，并且不能引起更多的事情。损害超出您的承受能力。
在2009年的Velocity会议上， John Allspaw和Paul Hammond解释了对开发人员访问生产的重要性和实用性-但这种访问的大部分可以而且应该受到限制：
Allspaw：“我相信操作人员应该确保开发人员无需进行任何操作即可看到系统上正在发生的事情……没有什么比使用shell命令播放电话标签更糟糕了。 真傻。”
“为某人（即开发人员）提供生产硬件上的只读Shell帐户的风险确实很小。 没有它就很难解决问题。”
Hammond：“我们并不是说每个开发人员都应该在每个生产环境中都具有root用户访问权限。”
应该给需要访问系统的开发人员一个只读帐户，该帐户允许他们监视运行时–日志和指标。 然后强迫他们再跳一次，以获得执行管理功能或帮助进行修复和恢复所需的任何命令或写访问权限。
一个问题是，许多系统在管理员级别上的设计都没有细粒度的访问控制：有一个管理员用户（拥有应用程序，可以查看和执行设置和运行系统所需的一切），还有其他所有人。 破坏应用程序和环境的所有权结构和许可方案，并从支持和控制功能中分离只读监视访问权限 ，设置sudo特权升级规则 ，以及正确地跟踪和管理所有用户帐户，可能会很痛苦。
如果您没有适当地保护机密和私人数据或其他人可以出于自己的利益使用的其他数据，那么这一切都不起作用。 标记化或掩盖或因此它不能被读取的数据进行加密，散列关键数据，以确保它不被篡改; 确保未将机密数据写入日志或临时文件。
您还必须确保可以通过审核应用程序，数据库和OS来跟踪生产中每个人的工作，他们的看法以及更改的内容。 并使用OSSEC等侦探性变更控制工具跟踪对重要文件（包括代码）的更改。
所有这些检查和安全措施也使开发人员和Ops更加安全，并有望足以使审计师满意。
尝试使其工作
让开发人员从事生产工作除获得支持和故障排除方面的帮助外，还有其他好处。
开发人员与运营人员花费在生产问题上的时间越多，他们越会了解设计和构建实际系统所需的时间。 希望他们能以此为基础，设计更好，更具弹性的系统，并具有更高的透明度，并更多地考虑支持和管理员要求。
让开发人员共同承担使软件运行和提供支持的责任，证明他们在乎并提供帮助，将大大有助于打破运营与开发之间的困惑墙 。
这不是一件容易的事。 在您的组织中甚至可能根本不可能-至少在您的一生中都不可能。 您需要了解并平衡风险和优势。 您需要了解政治和治理方面的限制以及如何处理它们。 您需要采取适当的防护措施。 并且您需要确保遵守合规性和法规。 但是如果您不尝试的话，您会在桌子上留下太多的东西。
开发人员 生产环境账号
2099
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
