@qfdk 你是 CAP 的 欺骗感情 差评

@tyfulcrum 法国 INRIA 发来贺电

CAML 还存活着呢 哈哈哈

对的 可以开几个虚拟机来做实验

不过 zabbix 这个直接可以部署一到两个服务器上 好用的

不知道你们有没有自己开发的 web 也就是内网有没有 tomcat 之类的。 开发适合可以嵌入 elastique kibanna 然后直接把日志导入 zabbix 不知道有多爽

作为曾经的 CIO， 我来试着回答一下你的问题。

首先关于解决方案，这个一定是存在的，但能不能解决痛点这个还是个疑问，因为你说的这种解决方案需要打通多个软件，这时候就需要适配，如果解决方案够强大适配够好，就没有问题，但是这种情况下投入的钱也比较多，不是一般普通企业可以承担的。

说一下传统欧美企业做法：

首先制定 workflow， 可以使用 VISO 或者 BPMN 等软件来画。 然后根据流程图来进行分析看哪些步骤可以自动化实现或者说自动化最大化， 之后看是否有现成的解决方案或者说是一些小程序可以帮忙，或者最简单的就是制定出开发计划，将需求细化找一个或者多个实习生来做所谓的“解决”方案。

另外说一下作者说使用 SCCM 来实现自动化配置，这个真的不错，不过准备过程有一些漫长，因为需要合理安排软件自动安装的顺序，不过一旦制作出来，直接电脑连上网线就能实现从 0 到全安装定制 真的很方便

AD 等账户的控制，可以使用 JAVA 或者 C# 编程解决，或者说用 powershell 也是可以的，需要分析具体的触发条件，或者说是直接服务器定制服务

Zabbix 作为开源的工具，实战起来很好用，但是要注意主机存储空间。

主要是论坛这种东西 看得人多 评论留言的人少，因为很多不如 app 好用 即使有移动版适配

其实需求分析是一方面，最重要的是需求分析的粒度不同可能会导致开始的整体架构的变化。

我觉得一定要把握好需求的粒度， 从你的描述看来，好像是客户在不断的更改需求。

建议敲定要发的版本的需求，做相应开发测试发版。

用户提出的分享等新的功能，如果没在之前的需求分析中提及，就放在一边开发采集并且用户认可过的需求，交付.

新的需求要求他们再付费分析，开发

不要谈什么覆盖率 你业务规则至少要全部覆盖吧

拍一拍 继续吃

你说的是服务器日志 还是 APP 日志

如果是服务器运行日志 ， 可以使用 zabbix 进行全局监控，集成 kibana


如果是 app 运行日志， 可以直接通过配置 kibana WS 地址，多个 apps 可实现通过远程写入 kibana

直接 kibana web service 写入就好了啊

网上买 或者从比较好的朋友那里拿

@anyele 看环境表示很正常，很多程序估计最早都是都是从 VB 上来的，所以很多人习惯使用存储过程。 如果是移植的项目，也就是说现在的程序是 C# 是之前从 vb 移植的，那就不难理解为什么这么做了。 如果是新项目，估计是别人不习惯用 entity ？

你自己改了 22 端口，新端口是不是没加入可访问列表啊 控制面板链接看看吧，不行就开单找客服咯

不考虑其他列重复的情况下，可以将本地数据库表不带主键依次导出 然后倒入生产数据库

你的意思是现在是多个 java 本地服务器配置了多个数据库，现在要集中把每个本地库里的数据导入到生产库里?

你们的开发生产环境是什么

我来了 搞事情

你谈到数据库使用的问题，我在此说说自己的一些经验，当然不一定完全对，欢迎指正


－ 很多人把业务逻辑写入存储过程，你的意思是用 Stored procedure， 这种用法其实也有优点，就是简单的维护只在数据库端做修改就好了。 同时呢 procedure 可以帮助完成整个交易过程，对于一些对 transaction 支持不好的编程语言来说是不错的选择，有时用来做数据访问的优化


－ 不把业务逻辑写入存储过程，比如使用 JAVA 编程语言，可以使用存储过程来进行对数据的访问，但是有 JDBC Hibernate JPA 这些框架，我们可以直接使用，同时呢他们又比较好用，这时候没有必要使用存储过程来访问数据，当然也不是完全禁止的。但是要知道如果存储过程中有业务逻辑，JAVA 业务层也有业务逻辑，这时候代码很难维护，也很难做测试的