我们每个人都喜欢谈论我们的成功，而不是真的不喜欢谈论失败。 但是，错误经验通常比成功完成业务所带来的收益更有价值。 因此，我今天想谈一谈这种情况。 所以走吧...
锅，不要煮！
这个故事发生在几年前，即我作为1C开发人员的职业生涯的开始。
我们公司中出现了一个项目，以优化一个非常受人尊敬的客户的一个非常繁重的基地的运营。 客户端使用了如此偏执的安全服务，以至于无法从外部对服务器进行远程访问。 为了将基地直接连接到我们的办公室，安装了带有硬件VPN的单独局域网，并安装了经过严格协商的软件的工作站。 当然，没有本地管理员的权利。
像任何其他此类项目一样，它始于数据收集。 假设我们将首先在一个月内收集各种指标，然后我们将致力于优化信息库本身。 在这种官僚环境中花了多少时间来建立「我的客户中心」，这是一个独立的故事。 但是现在，在某个时候发生了，MCC已配置并启动。 之后，执行此项目的专家（Dima，嗨！），坐上了豪华轿车，环游了我们广阔的国家，然后去了更多的邻国。 但是事实上，我仍然了解甚少，也不知道如何做，但是我已经被认为是一个负责任的开发人员。 因此，在离开之前，德米特里（Dmitry）指导我完成一项非常重要且严肃的任务：每天两次，在峰值负载时，我必须去那台非常机密的计算机并在MCC中开始测量，然后在一个小时后将其关闭。 说明非常简单明了：
-看，您按下绿色的小按钮“播放”，运行不同的图表，等待一个小时，然后按下此按钮-“停止”。 仅此而已。
有什么会更容易的，对吗？ 我在数学系学习了5年是徒劳的吗？
我整周都在早上和晚上严格遵守这一习惯。 直到最后一天一切都很好。 午餐后，像往常一样，在星期五，我开始收集数据，然后……嗯，您知道它是如何发生的……星期五，晚上，我们需要完成一些紧急的事情，完成一些任务，下班后将我的妻子带到我的婆婆身边进入一家商店，第二家，等等。 总的来说，我离开了工作，完全忘记了命运多M的MCC。
星期六早上开始打个电话。 我们在客户那里获得了所有第1C个基地。 阿奇通与灾难！ 我们的专家在Dzheyrakh和Pasanauri之间的某个地方，位于网络访问区域之外。 客户的主要管理员也在某个乡间别墅中，无法进入。 尝试通过电话查找原因是什么？ 不知何故，事实证明磁盘空间已用完，因此1C代理服务启动了。 在这里，我已经开始怀疑...
您还记得，没有udalenka。 该计算机不仅与Internet隔离，而且与我们的本地网络隔离。 没事-要上班。 在准备和开车时，管理员意识到整个地点都由MCC日志占据，并做了他们认为最合理的事情-他们通过任务管理器将其切断。 来吧 您不仅可以从磁盘中删除日志，而且还会丢失测量数据。 他们以某种方式在网络共享上找到了足够的空间，并将文件复制到那里。 工作似乎已经恢复。
周日早晨开始打个电话。 我们在客户那里获得了所有第1C个基地。 Achtung和灾难需要两个！ 所有的恐慌都结束了-这个地方结束了。 但是，如何呢？ 我的客户中心已关闭？ 急着我要再次工作，扔掉原木以释放空间。 他们都在成长，该死！ 在担心执行最错误的情况下，管理员禁止我启动任何东西或进行任何配置。 在周日的其余时间里，我坐在电脑旁，将原木复制到球上，以使底座不再起床。
直到深夜Dima才与您取得联系，并说您只需要删除1C服务器上的一个小文件。 后来，几周后，我在一本著名的“办公桌”书中读到了关于他的书，但是那天，疲惫不堪的酷刑回到家睡觉。
星期一早上，我们的帐户被冻结，直到德米特里（Dmitry）休假回来为止，而且我的帐户也很清楚地说：“这样我们就不会再见到他了！”
这就是我的第一个优化项目结束的方式。
漏斗两次
大控股。 全国共有18个配置相同的信息库。 更新每周进行一次，并且遵循相同的惯例：交付文件必须事先准备好并上传到云中，并确保已在所有分支机构下载（即使在2018年，某些地区的Internet速度比典型的1C：ERP慢），检查是否在所有地方都创建了备份（我们似乎对此不负责，但是痛苦的经历教会了我们安全性），然后在每个分支机构手动运行更新脚本，并确保更新脚本没有错误。 通常，在最后一刻，发现交付中还必须包含另一个任务，这是一个较小的更正，因为下一次更新仅在一周内。
就是那个时候。 一位经验丰富，经验丰富的开发人员在将任务转移到战斗电路时，在一条线上犯了一个错误。 该错误被证明是严重的，它是在更新所有数据库后发现的。
那么该怎么办？ 开发人员快速修复了代码。 不让任何人测试：
-是的，有垃圾...我不能在一行中犯两次错误？
一个小时后，第三次更新了18个分支。
谁可以
一位Skype同事讲述的故事。
[同事]：很久以前就有一个“有能力的开发者！” 他有开发装。 他想开一个测试，但错过了，开了一个富有成效的...
[同事]：但这是否可以阻止“有能力的开发人员”？ 不行
[I]：在更新时，他不知道那里有人坐在那里吗？ ）））
[同事]：此外，他看到konf受到支持...但是您认为这可以阻止“有能力的开发人员”吗？ 不行
[同事]：他从支持中删除了配置（！），并看到他的mod绕过了所有存储库...
[I]：不是！ 完成故事，动态更新）））
[同事]：更新...系统显示：“数据库中有18个活动会话！”。 但是，这怎么能阻止“有能力的开发者”呢？ 不，不再！
[同事]：他更新了数据库并将任务传递给测试...
[同事]：顾问找不到衣服，直到很长一段时间后，他才意识到自己错过了。
[同事]：我不得不责骂他...
[同事]：我在给他打电话...我在电话里笑...
[同事]：我只是不明白...
运输崩溃
这个故事是由一位同事讲的，并用他的话记录下来。
它发生在一家大型物流公司。 大多数业务流程都集中在一个信息库中。 2012年具有竞争力的用户-全国各地的约3,000人。
设置一个简单的任务。 据他说，他做了自己的信息登记簿，其中的数据是在某些文件过帐后写入的。 尽管文件类型不多，但是每天这些文件的数量却是巨大的。 从理论上讲，我添加到寄存器的写操作不会给系统带来沉重的负担。 但是该任务的实现有一个细微差别-记录一个集合时，Overwrite属性设置为False。 也就是说，每个文档中都有添加的条目到寄存器中。 根据问题的情况，这是必需的，但实际上并没有影响性能，因为 根据选择条件，总会有1-10个条目。
功能测试成功。 我们处理了几十个文件，确保寄存器中的条目正确无误，没有发现任何可疑的内容，并将其发送给生产人员。
在那个不幸的星期五早上，我们更新了战斗基地，用户开始工作。 3000个人欣喜地填写了文件，并且寄存器中开始充满了数据。 在检查一切进展顺利之后，几个小时后，我们带着镇定的心回家（我们在不同时区与信息库的主要用户一起工作）。
应当注意，运行IS的服务器几乎是1C下在俄罗斯使用的功能最强大的服务器之一。 但是几个小时后，“出了点问题”（c）。
用户开始注意到系统性能下降。 所有操作开始放缓。 对任何动作的响应时间更长。 设备的负荷稳步增加。 当IT部门了解正在发生的事情时，系统中的工作几乎停止了。 设备无法应付，磁盘上的队列比俄罗斯邮局长。 如果设备较弱，则几乎可以立即发现问题。 但是最强大的服务器英勇地抵抗了我弯曲的手半天。
从MSSQL的“言语”来看，最严重的请求突然变成了我的寄存器中的读取请求。 虽然我没有做任何阅读。 在1C代码中很快发现了一个问题。 我忘了在一组记录上进行选择。 如果将“ Overwrite”属性设置为“ True”，那么我将立即发现错误，因为 每个条目将清除整个寄存器。 但是在我们的情况下，这没有发生。 当然，在十几个文档的示例中，我们没有发现任何性能损失。 但是，当寄存器开始充满成千上万的行时，系统每次都必须检查整个寄存器中是否有匹配的记录。
到那时，据一些用户称，运输已经崩溃，因为 汽车没有从1C处收到文件，也无法离开卸货点。
因此，“只是”忘了在记录集中进行选择，所以我输入了俄罗斯最大的1C数据库之一。
PS另请参见：