@echo1937

可否透露贵公司的规模，我比较感兴趣什么情况下适合用 PaaS 内部替代私有解决方案。

我说的黑盒不太精确，本意是想说 docker 镜像本身还是个依赖链条，现在封装起来了不代表不用解决 docker 内部的问题了。

第二个问题是，即使你内部所有的模块都按照服务的方式重建了，也有很多问题要解决。最直接的是 Provision 相关的部分。以前要实现具体到模块的监控功能，现在以 OpenShift 的管理功能来看，并不能接管原有的监控体系，还多了 OpenShift 的监控要操心。

我在 beta 时期尝试过，说实话不太好评价。毕竟 OpenShift 是 RedHat 的项目，它解决问题的思路就是“一体化解决方案”。实际上 Docker/Kubernetes/Atomic 无论哪个部分单独拿出来都是相当复杂的。从运维人员的角度上说，使用这种黑盒嵌套的黑盒心里应该有所抵触吧。

如果当成 PaaS 来用的话，一般只有不差钱才会选择。并不是说这个东西用起来有多贵，而是你一旦迁移到它的平台，想要再次迁出就不是那么容易的事情了。

如果想自己部署 Origin 的话，这个东西大概是市面上唯一的选择。自从我关注以来它的核心设计就变过两三次了，不过这是 beta 时期的情况。对于生产应用的话，可能还是有些仓促。另外这套系统的学习成本很高。

有个一直困扰我的问题是，这种为了解决运维的技术手段，怎么把它集成到企业现有的开发构建流程中去。无论是 PaaS 还是独立部署，不一定比运维人员维护 docker+kubernetes+linux 更容易。

@zonghua 你的专业要对口，基本航空航天、机械，资源能源行业，电信通信行业都是这样。但法国国企的晋升跟中国国企差不多，背景出身比能力重要。

@lengjingxu 我 11 年曾经在 orange 的所谓互联网部门干过，不过自己走人了。最大的问题还是大家工作没有压力，解决问题的思路都是建立在无竞争对手，也没有资源限制的环境之上，也就没有创新的动力。

说 ovh 是互联网公司的原因是它确实是技术驱动的。它最早是完全没有客服的，客服电话会直接转到负责的工程师手上。这几年的情况不太清楚。

法国现在的创业公司集中在硬件行业，包括风投的方向也是如此。总体来说，创业是有钱有资源才会考虑的。

你的感觉一点没错。一般意义上的“互联网”公司是极少的。在我看来， ovh 算是一个吧。

这样的现状是由很多原因造成的，法语文化可能是其中最不起眼的因素。

法国的并没有像国内这样的对于中小企业的扶持， PME （中小企业）的负担和一般大中型企业没有什么两样。对于追求小团队高效率的创业型企业或者互联网企业来说，意味着在融资之前，你要有更加充足的启动资金支持，对于自身造血能力的要求也更高。简单说，法国的互联网公司的入门门槛要高得多。

相对来说，法国的员工成本要比其他地方高不少，这是高福利国家的通病。同时法国的工会是有非常强大影响力的，雇人容易，但是一旦签订 CDI 想要解聘就是风险和成本非常大的事情了。法国实行的是 35 小时工作制，而员工一年的带薪假约有 30 天，实话是说，对于互联网行业来说，你拿什么和那些一周工作六天，每天十个小时的公司来竞争？

法国大多数行业是禁止负债经营的。（最典型的例子就是足球俱乐部，除了 psg 没有俱乐部有钱买球员，都是从青训培养）这对于互联网公司来说，由于现金流的问题死掉的可能性要大得多。互联网企业前期不盈利是常态，但在法国这样的做法可能行不通。

除开政策类的因素，人才是另一个限制因素。

除开少数名校，法国一流的大学就是工程师类的。然而计算机科学（ Informatique ）大约是 2005 年前后才逐渐成为工程师大学的专业之一。且不说教育水平如何，仅仅从数量上每年毕业的工程师也不过几万人，平均到计算机科学专业其实没有几个人。就是这寥寥无几的毕业生，基本都在毕业之前的校招被法国的大型国企签走了。换句话说，即使你想组建一个高质量的人才团队，市场上也招不到合适的人才。

go 1.5 之前， GOMAXPROCS 默认为 1 。之后默认为核心数量。 go 1.5 重新实现了 goroutine “调度器”。

由于 goroutine 是在 thread 的基础上进行复用的，所以最终在 cpu 核心上体现的占用率还取决于内核调度器的实现。

remapkey
Windows resource kit (for win 2003 ) 集成的一个小工具， win10 有效

我记得我吐槽过 ovh （法国）人工服务来着，客服基本是个转接员，直接转给机房工程师，当然打通电话的难度比较高。

不过技术上说，这种非共享类的部署更简单，反倒是那种虚拟化的共享比较麻烦。

@martinmax 不好意思，我不是

@Livid 不小心关掉了通过微信号查找，现在应该可以了。

单纯说需要个解决方案的话可以考虑 csync2 。

合理的做法是修改应用存储逻辑，重做存储系统的结构。

根据 CAP 理论（ https://en.wikipedia.org/wiki/CAP_theorem ），实时性、一致性和可用性三者只能取其二。

@c742435

docker 用 loopback 后端一定要把 loopback 设备映射到物理硬盘上，不然性能问题太严重。
aufs 的内核补丁不管怎么说都是个隐患，能用 overlay 还是用 overlay 最好。

之前一直在用自己的构建系统，写明内核、工具链以及应用的版本，构建出对应的 vm 镜像。生产系统启动时抓取镜像。基本上 nginx 20MB ， python 50MB 这样。如果共用一个 4GB 的 vm ，对于网络和 io 的影响都太大了。

vm 确实不需要经常更新，但是还是会有变动的时候。实际上想吐槽的是全公司共用一个 vm 的行为。

coding 的这种做法短期看不出问题，等时间长了， 甲项目说要用某组件的 a 版本，乙项目说要 b 版本。公司说，你们研究研究，到底用 a 还是用 b 。指望靠人规定来解决依赖问题，相当不科学……标题里不是写着嘛，人、技术和流程，都人规定了，要技术和流程干啥。

技术支持就该说，你们愿意用啥就用啥，环境都能给搭建好，不冲突还能重现。

不清楚这是个什么会议，在座的听众是谁，我只是很好奇，很多内容明明可以用简洁的术语描述出来，却一定要绕开不用，好像怕听众听不懂一样。

技术层面一共三个大问题：

源代码版本依赖，使用 android repo tool ，算是解决了吧。

dev/staging/prd 运行时统一和标准化， vagrant/docker 只是表面上解决了问题：运行时的依赖转移到了公司级别的 VM 之上。只是这个 VM 就不升级了吗？下次组件更新的时候，还是要回头解决依赖问题。

这两个依赖问题并不能靠“全公司依赖同一个版本”来解决，时间长了，一定会出现的情况是新代码会依赖新版本，而老代码还没有针对新代码做匹配。除非所有组件的更新都有着 100% 的向后兼容性，但这是不可能的。

我觉得一个更合理的思路是，能够独立运行的组件，可以使用独立的依赖。问题转移到，如何构建和重现独立的依赖。不过从对 vagrant/docker 的使用描述来看， coding 还没有这个能力。

最后一个自动化 CI 的问题，与 Push on Green 理念不冲突，@just4test 给了很好的实现方法。

docker 可以 export/import 镜像或者 save/load 容器。

带门面的餐馆一般毛利率要有 50% 才能赚钱，外卖这种往夸张说算 30% 好了。 20 一份的外卖，成本最多 14 元。这成本还是摊薄的，其中物料成本还包括餐具什么的，菜品本身多少钱就不好说了。

别的不说，去菜市场看看菜价，你就是自己做饭，不算人力成本也得一顿 10 块钱了。

第一反应是大内斗省？

@noli

“所有的 CSP 不会同时被攻破”只能保证“数据分块不会同时被第三方获取”，但并不能保证“被获取的单一分块不会泄漏数据”。

所以结论就是，你的分布式设想，依旧要做文件级的加密才行。不加密我就可以说它不安全。

解决“隐私”问题的是加密算法，而不是你的“分布式”方案。如果你做产品这么宣传，那是另外一回事。

==========

一个系统的安全性，是由最健壮的环节决定还是由最薄弱的环节决定？理论上是最健壮的环节，而实际上是最薄弱的环节。

你的设想里有分布式模块和文件级加密模块，那么会存在两种可能：

- 分布式模块安全性更高
- 文件级加密模块安全性更高

前一种情况，你要关心文件级加密算法别被破解了（小概率）；后一种情况，你给一个安全系统增加了薄弱的一环，暴露了更大的攻击面。

从实际应用来看，多数应用都要依赖加密算法作为最后一道屏障，考虑到代码实现，几乎没有任何产品可以比纯加密算法能提供更高的安全性。

==========

你还是动手做一下吧，等你做过就知道哪里有问题了。

@noli

> 数据加密存在一个或两个 CSP 那里，然后加密密钥由另外一个 CSP 存储。
> 这样一定是存在单点故障导致整个系统失效的可能性的。

你混淆了“安全”的定义，从安全（ Security ）的角度上说，最终只取决于密码学算法和密钥管理，而多点存储关注的是可靠性（ Reliablity ）问题。虽然中文都叫做“数据安全”，但完全是两码事情。


我强调的是，分块之后你还要不要加密？

- 不加密，毫无安全性（ Security ）可言
- 加密，安全性（ Security ）等同密码学方案


如果你想解决与“隐私”相关的问题，你找错了方向。



另外你对于 entropy 的理解不对，能不能观察到 metadata 并不是决定熵多少的因素。（事实情况是，如果你能观察到 metadata 了，相对于加密的情况来说，前者的熵更低而后者的熵更高。）

http://yurichev.com/blog/entropy/

这里有非常详细的解释， entropy 分析价值比一般认知当中大得多。

如果文件本身没有加密，分块之后一样会由 entropy 泄露信息。如果加密了，单一 csp 也没有破解能力。

分块可以提供 (m,n ) 冗余，即只要总共 n 份分块的 m 份即可恢复。这可能是唯一优点。

你并不能提供密码学意义上更好的安全性，同时降低了易用性。