这个“可能”是运维操作失误导致被判了 5 年的案例有点意思。

• 資深大佬 : hellos

  不亏啊

• 資深大佬 : poorcai

  太长了没认真看，他这是恶意操作，还是平时工作中的正常操作导致的？

• 資深大佬 : Yourshell

  都偷偷存密码并使用了还可以有什么意思？

• 資深大佬 : eason1874

  偷数据库账号密码，用未经审核的代码私自操作数据库，导致业务异常。这哪里是运维操作失误这么简单。

  虽说初衷可能是为了方便自己工作，但这也只是一面之词，谁知道你会做些什么。

• 資深大佬 : jdgui

  偷记密码这个问题就很大了，你本来没这个权限的，你用非常规手段获得这个权限，这个根本就不是失误的问题。
  你想想那些因为系统出问题浪费时间的患者就知道为啥要给他判刑了

• 資深大佬 : kaiki

  在生产环境做测试，太刺激了吧

• 資深大佬 : zongren

  主说的有点意思是指什么？资本或者郭嘉要害这个人？

• 資深大佬 : murmur

  擅自对计算机信息系统功能进行删除、[修改]、增加、[干扰]，造成计算机信息系统不能正常运行，后果特别严重

  还是个医院，够行为特别恶劣了，判的没毛病

• 資深大佬 : si

  总结一下
  1.偷记密码
  2.用自己写“数据库性能观测软件”连接数据库
  3.软件执行锁表操作

  写个软件连接偷记下密码的数据库，这操作太迷了。

• 資深大佬 : dot2017

  这个软件公司看来缺少一套好用的测试环境啊#手动狗头

• 資深大佬 : crs0910

  感觉判的没问题，但是不算自首不是很理解。辩护人的辩护意见也很迷。

• 資深大佬 : oovveeaarr

  这个偷偷记录线上数据库密码的操作。。

• 資深大佬 : Lax

  “因为 2018 年 10 月份郑大一附院和郑州市公安局网监支队做网络安全攻防演练后，网监支队出具的安全整改通知书显示有这个账号的密码……” 展示的时候就超出授权了，正常还应该要求对方进行修改以避嫌

• 資深大佬 : mebtte

  判了 5 年有点多啊

• 資深大佬 : realpg

  刑事律师都是骗钱的系列的典型。。。

• 資深大佬 : encro

  有可能为了催尾款或者后期收维护费，
  留了一个后门，
  否则没事去锁表干啥呢？

  话说突然觉得医院钱真多，
  一天 800 万。

• 資深大佬 : encro

  结论是医院的信息千万别去看，
  太机密了，
  看一眼就坐几年啊。。。

  公立医院的财务有监控吗？

• 資深大佬 : realpg

  @mebtte #14

  就按我检索到的庭审、材料等资料，判 5 年一点也不多，而且基本是贴着检察院建议量刑标准的底下走的。

  国内普遍刑事律师都是骗钱的典型

  哪怕非常有名，根本不到点子上

• 資深大佬 : wangyzj

  https://wenshu.court.gov.cn/website/wenshu/181107ANFZ0BXSK4/index.html?docId=3393ae7dac8444338252ab250099add4

• 資深大佬 : EricCartmann

  总监刚刚转发到公司群里，扭头就在你这看到了。

• 資深大佬 : guog

  @encro 你也不看影响了多少机器

• 資深大佬 : also24

  所以 chksm=zhangxiaolong 是什么参数？

• 資深大佬 : dazkarieh

  五年对于这个罪名而言太正常了，根据现行刑法，所有对于计算机信息系统数据的删除、增加、修改、干扰行为，无论是否危及计算机信息系统功能的正常运行和安全状态，都会被视为符合 『破坏计算机信息系统罪』的罪状描述。

  2011 年最高法、最高检导意见虽然提出了量化意见，但其实际上是弱化了后果与计算机信息系统安全的关联性，或者说使得仅造成他人经济损失 /自己获利而未影响计算机信息系统安全的行为也极易被圈入破坏计算机信息系统罪。

  所以有某些法律学者呼吁这一罪名正在被 ‘ 口袋化’ ，破坏计算机信息系统罪迟早会成为网络信息时代的“口袋罪”。

  —-

  《最高人民法院、最高人民检察院关于办理危害计算机信息系统安全刑事案件应用法律若干问题的解释》已于 2011 年 6 月 20 日由最高人民法院审判委员会第 1524 次会议、2011 年 7 月 11 日由最高人民检察院第十一届检察委员会第 63 次会议通过，现予公布，自 2011 年 9 月 1 日起施行。

  第四条 破坏计算机信息系统功能、数据或者应用程序，具有下列情形之一的，应当认定为刑法第二百八十六条第一款和第二款规定的“后果严重”：
  （一）造成十台以上计算机信息系统的主要软件或者硬件不能正常运行的；
  （二）对二十台以上计算机信息系统中存储、处理或者传输的数据进行删除、修改、增加操作的；
  （三）违法所得五千元以上或者造成经济损失一万元以上的；
  （四）造成为一百台以上计算机信息系统提供域名解析、身份认证、计费等基础服务或者为一万以上用户提供服务的计算机信息系统不能正常运行累计一小时以上的；
  （五）造成其他严重后果的。

  实施前款规定行为，具有下列情形之一的，应当认定为破坏计算机信息系统“后果特别严重”：
  （一）数量或者数额达到前款第（一）项至第（三）项规定标准五倍以上的；
  （二）造成为五百台以上计算机信息系统提供域名解析，身份认证、计费等基础服务或者为五万以上用户提供服务的计算机信息系统不能正常运行累计一小时以上的；
  （三）破坏国家机关或者金融、电信、交通、教育、医疗、能源等领域提供公共服务的计算机信息系统的功能、数据或者应用程序，致使生产、生活受到严重影响或者造成恶劣社会影响的；
  （四）造成其他特别严重后果的。

• 資深大佬 : also24

  @encro #16
  你要知道，郑大一附院是全球最大医院，床位数上万张，2017 年营收就破了百亿。

• 資深大佬 : opengps

  这不是运维操作失误，这是运维违规操作！

• 資深大佬 : wdlth

  生产库还能随便连的？

• 資深大佬 : villivateur

  https://img.vvzero.com/ih/2020/04/19/ffd4f874913a1.jpg

  这条可真有意思，呵呵。

• 資深大佬 : encro

  @also24

  忽然想到，公立医院如果上市，公布财务。。。
  那么。。。国家是不是能少贴好多钱进去？

• 資深大佬 : hstdt

  不看裁决？都明确是导致的原因了，根本就不是疑似。

  另有一些其他想法。

  先说作死去搞密码，这一步应该算偷窃公司机密？

  再说上很多人提的不允许操作生产库，是否有纸面上的公司标准或者国标？应该只是行业建议标准吧，真操作生产库的大把的人，都抓起来么。开车可能致人死亡，所以不允许开车？

  再继续，那如果是开发环境的 bug 上线，导致相同后果，会被判一样的刑么？因为这个罪感觉就是从造成严重后果上来判的。

  感觉相关法律还是很不完善，这些操作方式和情节严重程度都没描述，真的像是口袋罪。

  我法盲，就听了罗老师几堂课，把自己想法发一下。

• 資深大佬 : redtea

  夏某在这家公司不是普通员工，是股东、董事。

• 資深大佬 : NeinChn

  看了一下刑法这些条例，感觉做程序员是不是太危险了，就从后果来看，大厂程序员一个 bug 随随便便就进去了
  而且从“经郑大一附院出具证明：由于恶意锁表行为遭受损失等相关情况”和全文看下来，没看出哪里恶意了
  如果只是用了不合理的方式进行正常监控和维护，导致的损失，这种至少不涉及刑法吧
  怎么判断恶意和非恶意也是个问题。。。

• 資深大佬 : fuchunliu

  @NeinChn 没授权还不是恶意呀。

  有人通过非法手段复制了你家钥匙，然后进你家里把你家里值钱的东西损坏了，辩解说是不小心弄坏了的，这不一个道理吗？

• 資深大佬 : dremy

  BAT 各种故障多了去了，也不见真有杀了祭天这种操作…

• 資深大佬 : statement

  之前在做医院信息化这块，算医疗行业前十，服务大几百家医院，自己能接触到的十几家，生产环境没任何权限管控，服务器数据库随便进，新人刚进来基本上就能接触到，但也没谁虎到搞破坏要吃牢饭的。

• 資深大佬 : Tink

  主要两个问题，一是私自偷记密码；二是把未经测试通过的软件直连生产环境数据库

• 資深大佬 : statement

  经常下班在公司或者在家连公司电脑再连医院电脑，还误删过医院生产环境表。表示有点慌。现场实施报问题让你去处理，也没人授权，至于数据库密码 服务的所有医院基本上来来回回就那两个。 现在感觉好慌。

• 資深大佬 : yyysuo

  程序员一定要注意保护自己啊，宁可不做事，也不能违规操作，这判决，别的没问题，非得判恶意，有点过分了。

• 資深大佬 : chiuan

  这个太可怜了。

• 資深大佬 : NeinChn

  @fuchunliu 他是运维吧，写的东西也叫做“数据库性能观测程序”
  这个事情细节太少不好评价，虽然我不能理解为什么“数据库性能观测程序”要密码就是了。

• 資深大佬 : ajaxfunction

  @NeinChn 肯定不是单纯的程序员失误，这里绝对涉及总包分包佣金结算，尾款结算中的问题。
  我们之前给煤矿上做的系统 问题多了去了，领导也不会说怎么怎么样，因为大家都是利益捆绑，顶多把底层员工数落一番，然后找新方案顶上

  案中信息化建设 目标金额肯定在千万级别，医院敢这样光明正大的报警抓人，没有其他瓜葛我是不信的

• 資深大佬 : dnsaq

  主要有两个问题：1.私记密码 2.未经授权连接生产环境数据库
  私自记下密码我觉得可以理解，可能是怕医院的人忘记密码又找他，到时候双方都没密码就沙比了，另一个可能是为了方便自己，综合结果。我也有留一份密码的习惯，因为公司有些脑残就是不记好密码(低能儿太多没办法为之)。对于未经授权连接生产数据库，这个绝对是自己没事找事，连接看看也就算了还拿未经测试的软件去操作，我只想说这哥们儿心真大，5 年就当买个教训吧。

• 資深大佬 : Hyejeong

  喜提我司的 HIS

• 資深大佬 : min

  明显是故意的，绝对不怨

• 資深大佬 : panzhc

  @redtea 董事里面确实有姓夏的，不过怎么确定就是这个人呢？

• 資深大佬 : panzhc

  看到裁判文书了。。。

• 資深大佬 : janus77

  生产环境做测试，要么是非常新的新手，要么是非常老的老油条，这人明显属于后者，只能说这次正好出事了。其实他自己肯定是知道可能出事的后果的，往小了说也会扣工资，那往大了说自然也就可以定罪了

• 資深大佬 : diferent

  @min 你看一下判决书吧, 根据证人证言看, 应该不是故意的.
  别自己主观判断.
  但是厂商和医院的纠葛就不好说是怎么回事儿了,
  一般遇到这种情况,是不会判刑的, 不知道为啥,这个会定这么重的罪.
  跟医院打过交道的都知道,医院这种 IT 水平弱的一批,直连生产库是常事,记密码也是常事.
  但是问题在于, 他记录了别的厂商的密码,如果记录的是医院自己操作员的密码可能都没事儿.
  估计是 B 厂商被误伤了,之前被狂喷,结果发现端倪,故意把事情搞大.

• 資深大佬 : janxin

  这可真不是失误…

  怕不是有心做的，还是要看动机的

• 資深大佬 : janxin

  @janxin 看了一下判决文书：

  夏文帅在未经授权的情况下，趁被害单位修改密码之机私自记录上述账号和密码，并私自开发应用“数据库性能观测软件”，私自使用该账号密码连接被害单位 his 数据库，使其编写的锁表语句在 his 数据库运行，导致被害单位的门诊业务系统瘫痪，造成重大损失。

  夏文帅作为专业技术人员，应明知其违规操作可能造成被害单位计算机系统不能正常运行，而放任该结果的发生，属于间接故意，应对危害后果承担法律责任，符合本罪的主观构成要件。

• 資深大佬 : jatai

  mmp 我一做前端的，公司老是给我数据库帐号密码，还特么是线上的，以后不叼数据库了

• 資深大佬 : zydrsnuo

  我觉得就是单纯失误，不一定有主观恶意。IP 地址都 xjb 配，规范意识

• 資深大佬 : zydrsnuo

  我觉得就是单纯失误，不一定有主观恶意。IP 地址都 xjb 配，规范意识能有多强？

• 資深大佬 : wangxiaoaer

  1 偷记密码，看他的动机和目的是什么，现在看来是为了运维方便，做过这种业务系统的都明白，甲方没几个能记得住密码的。

  2 生产数据库操作：尽量避免吧，尤其是这种运行不间断业务的系统。但有时候直接连上去看一看快捷、方便。

  所以感觉是玩大了，至于恶意不恶意要看他是否打算获利，目前看来没有。

  另外有几个疑问：

  1 写的这个数据库检测程序为啥要通过锁表进行并发模拟，这不是测试过程中的工作吗？ 运维过程应该是看看连接数、资源占用率之类的吧。

  2 医院的数据库可以互联网直连？ 照这个情况看，里面的敏感数据加密也是不可能的了。这也是为啥我特么看到智慧医疗、各种扫码挂号、支付就恶心的一笔的原因。

  3 以后这种技术类案件能否找一些专业人员把把关，写出来的东西真是一言难尽。

• 資深大佬 : fuchunliu

  @NeinChn 他是运维没错，查看数据库运行状况也没错。

  主要是是他使用的是非授权的账户密码，没有明确授意他使用这个密码，这个相当于他非法获取的。出了事肯定得受罪。

  如果授权他使用这个账户密码了，肯定不会这么判了吧。

  所以跟他是不是运维还真没关系。

  不过我有一点疑惑：他运维运维，应该有授权的账户密码他为啥不用

• 資深大佬 : abcbuzhiming

  @NeinChn 那篇文章肯定隐藏了细节，别的不说，你为啥要开发一个程序 6 次锁别人的表？身为开发的程序猿不懂锁表是什么操作吗？它锁表肯定是有目的的，不然不会锁那么多次。所以说他有恶意没错

• 資深大佬 : silentstorm

  > 案发后，夏某某对其工作数据日志、办公电脑进行了清理。
  这个就不好解释了，心虚了？

• 資深大佬 : aniua

  @fuchunliu 极大概率是权限不够

• 資深大佬 : silentstorm

  @wangxiaoaer
  > 2 医院的数据库可以互联网直连？ 照这个情况看，里面的敏感数据加密也是不可能的了。这也是为啥我特么看到智慧医疗、各种扫码挂号、支付就恶心的一笔的原因。

  也有可能是过 VPN 连上去的吧

• 資深大佬 : AlexHsu

  运维为了方便直接自己写程序监控生产环境就是作死啊 而且他的行为没有书面邮件形式通知公司和甲方
  实际上运维中间有很多灰色操作 为了方便留存管理员密码 不出事则以 出事肯定凉啊

• 資深大佬 : redtea

  判决书里的服务器 ip 是怎么回事，查了一下是美国的 ip 。

• 資深大佬 : saytesnake

  不懂数据库…不明白为啥会这样…

• 資深大佬 : Vegetable

  您就是标题党？

• 資深大佬 : belin520

  请主亮出你的观点，以便讨论

• 資深大佬 : mywaiting

  照这个损失来判刑

  我翻一下先前微盟的 xxxx 删服务器事件

  是不是该直接死刑了？

• 資深大佬 : 526326991

  我以前就是对接医院 His Lis 这类系统数据的 现在想想 还好当时萌新 不敢乱动
  否则 现在在牢里了

• 主 資深大佬 : matrix67

  @zongren #7 @belin520 #63 我说有没有这么一种可能，本来开发锁表功能是另有目的的。然后没搞好，在临时写了一个测试程序说是锁表操作。上有人也提到了。

  主要数据库性能观测，不是一个过程么，或者理解为一个监控软件。

  @statement @dot2017 #10 你看影响民生的重大软件工程，也是在随便搞搞 🙁

  @Lax #13 这个也是个槽点。。。

  @encro #16 是啊 很奇怪

  @also24 #22 就是测试一下，教张小龙做软件。。。。 逃）

• 資深大佬 : fire2y

  以前一个医院的合作项目，同事直接把库全部考下来了

• 資深大佬 : psirnull

  IT 属于高危行业

• 資深大佬 : hoythan

  淦，医院 2 小时损失 800 万。

• 資深大佬 : hanbing135

  出了这么大事 不杀个码农祭天怎么平复悠悠众口

• 資深大佬 : dodo2012

  我看好多人是根本没看内容就开始张嘴，写的清清楚楚，他自己偷偷记录下了修改后的密码，

• 資深大佬 : uxstone

  面向监狱编程

• 資深大佬 : dbskcnc

  这个不冤，以前已经干过若干次，当然就是那个测试程序的细节交代清楚（专业人员其实是可以看得清楚的），到底是真的在测试性能还是单纯恶意（恶心一下医院或者排挤对手）

• 資深大佬 : newmlp

  干完事也不知道粉碎下数据

• 資深大佬 : zhang77555

  其实医院的信息安全全靠法律加物理隔离加外包公司的良心, 真的

• 資深大佬 : vone

  14 、被害单位委托代理人杨扬的陈述：2018 年 12 月 24 日 8 点 17 分，我在郑大一附院河医院区办公，我看到微信上三个院区的服务群里说门诊业务系统卡住了，无法进行其他任何业务。我和同事以及东区的技术人员一起通过工作电脑查询门诊业务系统卡机的原因和查询数据库。在查到 82 号和 89 号这两个接口服务器时，发现数据包拥塞严重。在 9 点的时候，我在我们的 PL/SQL 里面发现了一条锁表语句（ LOCKTABLE+表名字，也是挂号业务表），然后我们就执行了终止语句（ KILL ）。我们一共执行了 6 次终止语句，门诊业务才恢复正常，这个时候时间是 10 点左右。后来我们将服务器工作日志导出发到东软公司总部进行分析，分析的结果是发现那个锁表语句是非程序中的运行语句，怀疑是人为操作，操控门诊业务系统。我们又请了郑州市信大天瑞信息技术有限公司的技术人员进行了日志分析，分析的结果与东软一致。这 6 次锁表语句的总共执行时间是 1 小时 34 分，从 2018 年 12 月 24 日上午 8 点 13 分开始到 9 点 47 分结束。这个锁表语句影响了郑大一附院的三个院区，分别是郑东院区、河医院区和惠济院区门诊的所有业务。在这 1 小时 34 分的时间内三个院区的 15300 多个门诊业务量无法工作，24 号当天的业务量是 25528 个。这次的恶意锁表现象严重影响了我们的日常门诊工作。
  15 、被告人夏文帅的供述和辩解：我们公司要负责对整个医院的数据库相关的硬件和软件设备进行维护，简称运维。我是 2012 年开始对郑大一附院进行运维相关工作，我主要参与到数据库的运维是从 2017 年开始。目前我们公司主要有张某 2 和我对数据库进行维护，为了能及时监控医院的数据库运行状况，我就没等到公司上班就登录系统对郑大一附院的数据库进行监控，这是我分内的工作。
  2018 年 12 月 24 日 8 点左右，我在北京家中用公司给我配备的联想电脑，远程登录到郑大一附院的数据库和小型机的数据库，查看数据库的运行情况。大概 8 点 30 分，我看到微信群里河医的门诊系统卡顿，我担心公司的综合信息运用平台也会出问题，就启动了我自己编程的一个程序（程序名称：数据库性能观测软件）对我们公司的系统进行查看。在我运行系统的时候发现我运行的这个程序在报错，我就更改了几次数据参数，一直没有运行成功我就主动放弃了，整个操作过程大概 20 分钟。大概在 10 点多的时候微信群说河医系统运行正常，我就去公司上班了。
  12 月 25 日我们公司将小型机的数据库的性能报告导出来，同事张某 2 将报告发给我一份，让我帮忙分析问题出现的原因。26 日我分析的时候发现小型机分析报告中第 9 条语句看着有点眼熟，拿出来跟我自己做的编程进行了比对，结果和我运行程序的语句一样。我自己推断可能是我运行的程序和性能报告第九条重叠，这个运行语句会造成锁表。接下来我就对我自己做的程序进行分析，发现自己写的程序是有问题可能会将锁表语句执行到 HIS 数据库中。
  “数据库性能检测”软件是我 2017 年 7 、8 月份自己写的，存在公司给我的电脑里，文件名叫 his.exe 。我用我自己原来准备做的 his 系统搭的框架直接改的程序，文件名没有进行更换。我写这个软件是为了监控我们公司的综合信息运用平台和郑大一附院的 his 系统。我点击运行这个软件后，软件界面上会有 3 个选项卡，一个是 his 数据库，一个是综合信息平台数据库，一个是参数配置。2018 年 12 月 24 日上午我点击之后，进了综合信息平台选项卡，接着我操作了个检查链接的按钮，看有没有正常链上数据库，接着软件就报错了。因为报错，我就关了“数据库性能检测”软件，从软件的后缀名为“ini”文本文档修改参数。修改完之后，我又重新启动这个软件，还是运行失败，之后我又改了改，总之一共运行了 4 、5 次，还是运行不成功我就放弃了。这个软件我写好之后运行过多次，没有问题，那时候这个软件只链接综合信息运用平台。我是 2018 年 12 月初把 his 系统链接到这个软件里的，当时的目的是想用我写的软件也能监控到 his 系统的数据库的性能，能方便我的日常工作。我把 his 系统链接到我的软件之后，第一次联网使用这个软件就是 2018 年 12 月 24 日上午，也就是出现报错的情况。
  我写的程序当中造成锁表执行程序的语句是 locktablefin_opr_registerinexclusivemode 。这个语句的功能是用来锁综合信息平台 fin_opr_register 这个表的。锁表的目的是为了模拟一下在高并发情况下的死锁情况，测试一下我们公司综合信息运用平台的性能。这个语句我记得是在 2018 年上半年写到软件里的。我写这个软件的初衷是为了方便日常工作，这个软件写好之后，我可以通过这一个软件检测 his 数据库和综合信息平台的数据库性能。我编写的锁表的设计是可以手动锁表和解锁，而且这个功能只在链接综合信息运用平台的环境下才起作用。
  连接我们公司综合信息运用平台的数据库链接配置 IP 地址有两个：129.1.168.33 ，129.1.168.34 。用户名：honryhis，登录密码： [email protected]!Hias2018 。连接河医数据库系统的连接配置地址有两个 129.1.169.37 ； 129.1.169.38 。用户名:zdhis;密码：gjb1299L3+Z6&$9 。我在进入数据库性能观测程序后，通过鼠标点击软件初始界面左上方的 HIS 数据库和平台数据库进行连接切换。我写的数据库性能观测软件运行之后，默认的连接是 his 数据库，后来我才发现这个程序有问题，如果我运行这个软件的话可能会导致锁表的情况。我是 12 月 26 日才发现我写的语句可能存在问题的，但是我不确定 12 月 24 日的锁表是不是我造成的。
  我设想的这个软件不是要在 his 系统里运行的，软件一启动就会默认链接上 his 的数据库，本来应该在切换到综合信息运用平台之后，我点击软件界面的测试按钮之后才能在综合信息运用平台里执行的锁表语句。由于代码编写的问题，可能存在软件一启动，就直接将锁表语句在 his 的环境下运行的可能性。我写的代码有问题，导致一运行就锁了 his 的挂号表，我觉得存在这样的可能性。我在 12 月 27 日左右使用 360 和火绒软件清理过电脑垃圾文件，我电脑里的火绒设定的自动清理，每天一清，360 那个不一定，我觉得电脑垃圾多就清理。
  我编写的“his.exe”软件（数据库性能观测软件）没有得到中科弘睿公司或者郑大一附院的授权，这个软件是我自己编写的。2018 年 11 月底或者 12 月初的时候，我在这个软件里添加了 his 数据库模块，之后没有进行过模拟测试。我编写这个软件之前没有向中科弘睿公司或者郑大一附院进行过报备或申请。我编写的软件代码写的有问题，程序启动时默认链接 his 数据库，由于代码编写有误，可能错误执行了在综合信息运用平台中才能运行的锁表语句。数据库性能观测软件执行连接到 his 数据库需要在编程语句里写入账号和密码，账号是 zdhis，密码是 gjb1299L3+Z6&$9 。账号是中科弘睿公司设定的，密码是医院设定的，也是医院安排修改的，我是具体修改人。这个密码专用于程序链接 his 数据库。上述账号和密码是郑大一附院的 his 程序用的，我使用过，我在自己编写的数据库性能观测软件里就使用了上述账号和密码。从郑大一附院授权角度讲，我是没权利使用上述账号和密码的。2017 年 10 月 31 日，郑大一附院网络安全加密实施仪式我在场，修改的 zdhis 的密码由 3 个院领导分别掌握各自的部分，我当时写了个修改密码的语句。这个语句在我电脑里有保存，我当时存到一个 txt 文档里。我存这个密码的时候是我私下偷偷存的，我给张某 2 说过我私下存有这个密码。我是管理人员，我想着存着密码以后我自己用了就方便了。郑大一附院的领导没有给我授权让我使用并掌握这个密码。我编写软件使用了 zdhis 的密码是我私下偷偷用的，没有跟任何领导汇报过。

• 資深大佬 : wupher

  在中国做技术真不容易。

  钱没挣多少，什么锅都跑不了。

• 資深大佬 : vone

  @matrix67 是他自己编写的运维工具，本来功能是监控数据库运行状态的，里面写的有 BUG,一打开就执行了锁表。

  证词说他是收到有人反馈系统有点卡，然后就像用他这个软件查一下是不是有异常。

  吐槽一下，这位运维把能交代的都交代了，能揽得都揽到自己身上。请的律师都是饭桶吗

• 資深大佬 : xuanbg

  这个锁表操作真是迷……你观测性能就观测性能好了，悄悄地看，别人也感觉不到。为啥想不开要锁表？

• 資深大佬 : futou

  都是在做有罪推定（认为存在主观恶意）…更有意义的是应该讨论：存在违规操作+造成损失+无主观恶意，应判间接故意还是过失
  另外讨论私自记录密码的，文中看到了两次医院暴露密码的地方：1. 修改密码时，2. 通知单。尤其第二次明显向多人暴露了。夏某不自己交代的话，证据链成立不了，但最后又没认定自首 2333

• 資深大佬 : surfire91

  @silentstorm
  > 案发后，夏某某对其工作数据日志、办公电脑进行了清理。
  这个就不好解释了，心虚了？

  被告人有针对这点的解释：
  “我在 12 月 27 日左右使用 360 和火绒软件清理过电脑垃圾文件，我电脑里的火绒设定的自动清理，每天一清，360 那个不一定，我觉得电脑垃圾多就清理。”

• 資深大佬 : lewis89

  按这个量刑，GFW 的某些工作人员 可以牢底坐穿了

• 主 資深大佬 : matrix67

  @vone #78 哈哈 是的 这也是一个槽点。 整个看来，大家都是在打酱油，然后着急的病人看不上病。。。。

• 資深大佬 : Ansen

  同运维，公司所有密码都在我这管着，瑟瑟发抖……

  感觉这运维被人拿来祭天了

• 資深大佬 : nrtEBH

  太低级了 东软这么大的公司运维就这水平？？

• 資深大佬 : crc8

  @encro 2 小时。

• 資深大佬 : cnuser002

  看过了文书，争议点我认为在于，“间接故意”是算故意，还是过失？我法盲，真不太明白。

  夏某的行为，给人好心办了坏事的感觉。
  量刑深度，从后果上看，虽不为过，但判决理由是感觉往故意上套的，这个有点过分。

  一则夏某没有作案动机，
  二则他的三个疑点是可以解释的。

  1. 首先 copy 密码这件事，虽不合法，但是对于 IT 运维外包来说，又算是个合情的灰色选择，肯定是方便了工作。

  2. 其次锁表也难说是故意的，文书说了，这个锁表的功能虽然是夏某写的，但是是给其它项目用的，在查看医院数据库时本不应该启动的。而夏某前后 6 次启动该程序，也是为了查看数据库发生了什么，听着也没毛病。

  3. 第三，夏某事后清理了电脑，但是根据自己所言，电脑清理是日常，不算掩盖犯罪事实，并且证言中也说了，夏某有主动接锅的意思。夏某接到公安电话后，主动投案，但是最终判决里，没有定性为自首，也比较怪。

  如果理由是过失，然后后果严重，所以…

  比较符合我对这个案件的感觉。

• 資深大佬 : fxxkgw

  操作上问题很多，这个大家都懂

  但是这个判的也太重了呀，尤其是那个法律里提到的 “特别严重”的例子，简直是几十年前的、计算机还是稀罕物时候的规则吧。

• 資深大佬 : wangkun025

  我觉得是东软的锅。
  又要马儿跑，又要马儿不吃草。

• 資深大佬 : irainsoft

  @cnuser002 #87
  1. 间接故意是故意，是可预见的风险危害（在生产环境下跑测试肯定是有风险预见的）
  2. 灰色但肯定不符合安全规定
  3. 接到公安电话后主动投案不算自首（因为公安机关接到了报案且已经有证据，所以才找他的），如果医院方面主动联系到他，他向公安机关投案，那叫自首

• 資深大佬 : encro

  这个案子重判的理由：

  1，造成经济损失较大（ 2 小时 800 万）；
  2，医院数据库牵涉敏感信息太多；（现在医院是最封闭的体系之一）
  3，估计还有其他龌龊事：运维没事去锁表？（我更怀疑没付尾款所以动动手脚或者偶尔卡一下收维护费？最后惹恼医院了，直接控制了连接的电脑逮住了证据，既然都走到这步了，哑巴吃黄连这外包公司也只能认了）
  4，我想不到任何运维性能检测的功能，需要一个“锁定数据库”的功能。大家也都知道，所以判决书看看就好了。

  重在警示，告诉大家什么是底线，不能碰。

  假设：如果备份了数据库，发现里面有猫腻，结果会怎样？

• 資深大佬 : arthas2234

  外包和小公司就是这样的，甚至大公司这种事屡见不鲜，怎么方便怎么来，权限是什么，安全是什么，可以吃么？

  我接过一个公司的兼职，生产环境 mysql 直接暴露在外网的，端口 3306，root 账户密码 mypassword 。第一时间就把问题反馈给他们了，这种事情没出事还好，出事了是谁的责任都说不清

• 資深大佬 : encro

  利用系统，
  帮人挂号，卖黄牛票，卖患者资料，
  不是不可能，
  一样样都是暴利啊。

• 資深大佬 : 2379920898

  运维也不是那么好干的。。

• 資深大佬 : murmur

  @encro 公布财务国家要出很多钱，现在如果患者跑了有的钱是要医务人员填的，一公布出来还让医务人员自负？

• 資深大佬 : sujin190

  @NeinChn #31 这个应该时是否授权、是否遵守规章守则和主观恶意有关吧，正常开发肯定授权过和符合规章守则的啊的啊，否则岂不是随便生产点啥，万一设计有问题就要坐牢到死，这样的话这个世界上的大部分产业都要凉凉了

• 資深大佬 : encro

  @murmur

  我敢打包票，
  公立医院如果上市，能成为 A 股最赚钱的公司，
  银行、保险、证券、基金公司恐怕都没有这么赚。

• 資深大佬 : stoneabc

  @encro 看什么级别。三甲当然赚钱，很正常，水平高的医院在哪个国家都非常赚钱。普通医院其实惨的一笔。。

• 資深大佬 : sobigfish

  @villivateur #26 当初的 暴风门事件（ 2009 年 5 月 19 日） 就绝对触犯到这条了，但貌似没人进去

• 資深大佬 : WaterMC

  相关的讨论不少，我自己看那个裁判文书，理解是这个量刑有它的依据，并不是部分 V 友担心的“技术背锅”这一说。下面这些内容，是我个人的一些看法，欢迎讨论。

  首先，有 V 友提出，说自己日常工作接触大量公司的涉密密码、核心密码之类的。这一点，其实和这一案例是有本质区别的。V 友的日常工作，是需要接触到这些密码的，而且这些密码也是客户、或公司主管领导正式或非正式的发给你知晓的（邮件或即时通讯工具信息），即使发生了生产事故，那也是按照生产事故来追责或判责。但是案例中，被告人是无权知晓涉案的密码的，从证人证词及被告人自述都能清晰显示这一点。

  其次，也有一点后端做技术的并不完全了解前端业务风险的影响和严重程度。案例中被告人自述，8 点半发现卡顿报告，开始做一些排查操作，然后到 10 点恢复正常。而且从自述中在 24 号当天就没有再做后续的跟进了，直到 25 号导出报告。

  第三：关于案例被告人的软件。被告人也自述说，火绒每日清理垃圾。但是，他的程序前一天已经发生故障，在故障没有解决的情况下，就默许火绒清理了日志文件，那么他如何进一步分析和修复他的程序问题。我个人主管认为合理的做法应该是备份或者留存故障日志文件，直至软件问题解决。而不解决自己软件的问题，也没有正式测试自己编写软件，同时还直接把这一有问题的软件部署在生产环境，这一点我自己认为是有很大的问题（我不是技术工作，如果这一点主观判断有误，那么欢迎批评指正）。

  第四，关于密码意外暴露的问题。实际工作中，避免不了出现案例中的情况，证人证言有提到，安全整改通知书里面，有暴露密码。那么作为当事人，应该友善邮件提醒客户方，密码已泄露，为了安全请尽快更改密码。同时自己避免使用这一账号密码，用来避嫌。但是案例中并没有显示被告人有提示客户更改密码，反而继续在使用这一密码。