其实工资水平低是正常现象，也是合理的。不正常不合理的是提到工资说要考虑环境，但是职位要求却没有考虑环境。

简单来说矛盾点就是公司认为求职者在薪资方面没有 B 数，求职者认为公司在 JD 方面没有 B 数。

:doge:

网络问题：
DNS 生效不是实时生效。
跨 ISP 有时会出现闪断现象，需要保持长连接的话这点无解。
带宽是指到 ISP 机房的带宽，跨 ISP 很可能带宽不足。

可靠性问题：
都得自己解决，如果觉得自己运气好，麻烦详细最坏的情况，看是不是能接受。

总的来说可以用，但是关键时刻出问题的时候也别太生气，反正生气也解决不了问题 :doge:。

然而 vs 社区版在一定前提下是可以用于企业开发的。

似乎 SQL Server 2016 之前官方都只有 HA 集群方案，负载均衡都得用第三方方案。

@leehon
真心好奇“好的运维”是如何解决这个问题。

无法修改架构或者优化代码逻辑的情况下，运维除了堆机器之外还有其他办法解决数据库并发问题？

如果需要调整数据库，优化结构、语句这个更像是 DBA 的职责吧？

@azh7138m 新的版本是基于 bhyve 的，速度还行。

@13246864965 失业中，囧。

@13246864965 好吧，今天心情还可以，就放点干货节约点你搜索的时间。

.Net 大户的选择：Windows Container 在携程的应用
https://www.v2ex.com/t/335653


Virtualization Documentation
https://docs.microsoft.com/zh-cn/virtualization/#pivot=main&panel=containers

总结一下吧。

默认的网络结构下，你可以把宿主机看成一个路由器，宿主机的内网 IP 就是路由器的 WAN IP，容器 LAN IP 就是路由器的 LAN 口，所有容器都是接在路由器的 LAN 口上，使用 P 参数暴露端口时就像在路由器上做端口映射。

你的情况是在宿主机上做 DNS 劫持，让两个域名解析为 127.0.0.1，这样宿主机访问域名实际是走的做了映射的 nginx 容器端口，但是其他两个容器是解析之后是访问自己。

解决方法：

1. 其他两个容器用 nginx 而不是域名访问 web

2. 把 HOST 的解析由 127.0.0.1 换成宿主机容器 LAN IP 或 LAN IP

切换到公网情况，这时为了保证所有客户端都正常，DNS 肯定是只能设置成宿主机的公网 IP，那么你不会遇到这个问题。在内网模拟的话，就是通过网关来劫持 DNS 记录，为了保证内网所有机器都能范围，那么劫持的记录肯定不是 127.0.0.1 而是你的宿主机内网 IP。

Windows 有容器，但是没 gui，而且这个还不像 xwindow，你没办法解决。win2016 上才是原生容器，其他都是跑在 hyper － v 里面的。

@kismetX 说到底你还是没知道原因，其实如果是在网关上做 DNS 劫持解析域名的话你这个问题就不会遇到了。

我记得 eclipse 下默认的 Java 编译器是 jdt，和 JDK 的编译器不太一样，可以自动解决编码问题。解决方法无非就是 maven 下也调用 jdt 编译，或者检查下 Java 文件的编码格式，如果一样的可以尝试在编译参数下指定编码。

哦，那建议去看官方文档关于 Network 和 DNS 这块的内容吧，希望能找到解决方法，洗洗睡。

宿主机配置 host ？也就是用 host 改了域名的解析么？
那么不用 127.0.0.1 而是改成内网 IP 试试。

默认配置是比较保守或者是开发配置，一般根据手册或者配置文件内的说明根据机器硬件、业务调整基本就 OK 了。

数据库要是能毫无代价的大幅优化性能，恐怕早就变成默认配置。VPS 性能要是能凭空优化出来，卖 VPS 的早就干了，都是钱啊。

@cuebyte 先确定自己速度快是因为能力强还是因为考虑的问题没有“老人”考虑得周全造成的。可以试探性的请教一下解决思路，或者直接看项目代码中与自己解决任务相同或类似的场景代码。

线上和生产经验一方面要主动参与，哪怕没你的任务可以留下来观察学习。

另一方面应该多去了解线上故障处理流程，能查到文档记录就更好了，可以用实际记录向老员工请教处理细节。如果没有记录或者请教不到，那就想办法接触到线上生产环境的监控数据，自己用数据来分析问题。

由于同事并没有传授的义务，所以请教过程中的试探是必须的，对于明显排斥的同事就不要自讨没趣了。请教的问题越明确越好，而且要带上自己的思考内容。

对于缺少分享交流习惯的团队可以考虑自己主动分享一下新奇玩意，也不一定是技术方面的，反正一旦有风气起来，没什么特别准备的话，一般也都是讲工作中的内容了。而且这也是一种试探和筛选，找到志同道合的人能事半功倍。

当然如果你们已经混熟了就当我没说。

想买 opensuse 的贴纸换掉 Windows 的，没找到地方卖

企图用简单理论来解决复杂问题就是耍流氓。

项目最重要的就是可控——时间、质量、成本都需要可控。

出现甲乙丙三种情况都是项目不可控的表现：甲在一定程度上让成本不可控，因为产生了浪费；乙则是成本、质量、时间都不可控，是严重隐患；丙虽然对时间、质量有一定的不可控，但是期望是正向的。

出现这种情况，首先就应该去解决乙的问题，无论是乙的任务难度过高还是乙技术水平过低，都应该先解决项目不可控的隐患。难度过高的任务可以交给甲解决，如果是乙本身的问题，则只将简单任务交给乙完成，或者让乙转为测试工作，项目内容主要由甲丙负责。

说到底作为 PM 说出这种言论无非就是期望技术人员能像机器一样可控，但是人不是机器，懒得去主动了解项目情况，所以企图用老板的角度来改善一下自己的处境。

作为老板的角度看，如果将技术人员的工作视为创造，那么甲和丙都是好员工；如果将技术人员的工作视为制造，那么丙最优，乙比甲优秀。

作为技术人员的角度看，自身发展和价值追求才能决定你该做哪种员工。

第一种人犯错的时候只要再花 2 天时间就能按时完成任务。第二种人只能消耗更多的时间。第三种人会被预期一天完成的项目经理怼。

如果第二种人运气好，按时完成任务说不定还会被奖励；第三种人一旦给他人产生总是会提前完成的预期，只要有不满足预期的情况就会受到批评。

从结果来看，第一种人总是能满足预期，第二种人基本不做期望，第三种人一旦低于预期就会被怼。

从当事人角度看，做第一种人最保险，做第三种人要看公司是什么样的公司。

既然后端技能必须有，不如招个后端好了。前端那块稍微有研究真的不难吧？:doge: