发现很多矛盾都是由于双方认知的原因导致的。
有个笑话是，老公回家一脸的不高兴，老婆猜测了各种原因，也忧心忡忡了一晚上，其实只是老公喜欢的一个球队输球了而闷闷不乐。
这里存在一个问题，我们为什么不能把问题说清楚呢？而且是双方都认为清楚的。经常出现的情况是一方认为说清楚了，另外一方其实根本没有明白或者听进去。而这种导致的结果就是认知反复。
美国产生的MBA的教育早期其实就是为了培养大家有统一的认知能力，这样公司内部就上下通畅了，公司跟公司交流也通畅了。当然现在出现了其他的意味了。
但是在家庭生活中呢？ 是不是也需要这样呢？ 还是媳妇说的都是对的？男女真的是两种不同的生物吗？
由于线上问题一直不断，导致开发要经常去查看日志，本来好好的在kibana里自己查，可因为自己日志不全，经常要看上下文，原先可能直接grep可以看上下文，结果现在在kibana里就不会用了，也不知道是因为懒还是啥。
研发的东西一直没有很好的文档传承，连个api的默认值是啥都不写，结果一帮人查了3个多小时，当初标上有那么难吗？
现在前后端各种紧密连接，后端也不能提前上，前端也得跟着后端，于是就这样你拖我，我拖你，提了说用中间层，将前后端分离，结果说就是没人做就给打回来了。
一个简单的判断用户所在集群的请求，后端自己不做，还非要放nginx里去判断，这也是懒到家了，说我们后端的判断逻辑跟你们nginx的是一样的，所以就还是nginx上做。按照这个逻辑也不要后端了，都nginx+前端行了，nodejs都能实现。
由此可见我们任务的划分的水平是怎么样的？以什么来定义微服务的分界线，这些都没定义清楚就开始上微服务，结果只是拖慢自己的进度，拖累所有的人。兵熊熊一个。
每次晚点回家，看到球子和小小球都睡着了，都有种莫名的难受，不说一声晚安就睡了啊。
家是港湾，每天累了一天，回家跟球子和小小球玩会，给小小球洗澡都会让我放松很多。
工作太累，就不要耽误大家休息的时间去进行聚会啥的，跟同事喝酒和跟家人兄弟喝酒真是有很大的不同。
家才是你真正的港湾。你的妻子，你的孩子，你的父母。
最近南汇滨海的塘下公路突然在网上爆红了，塘下公路 这可是我小时候成长的地方，居然一直没有发觉它的美，那时候只是感觉一条很普通的海堤路。
其实视频角度是空中进行俯瞰的，这是我们以前从来没有注意过的，而且在现在钢筋水泥的森林里存在这样一条两边郁郁葱葱大树的小路是更难得了。
也许这个路对于我父母是更有意义的，毕竟是他们年轻时候工作过的地方，最美好的年华都是在这里度过的。现在这条路基本也是断断续续的，很多地方都已经年久失修了，这样让它保证了最初的样子。在整个浦东地区大拆大建中，只有这些偏僻的角落被遗忘了。
虽然还是之前那个样子，但是现在换个角度也许整个感觉是彻底不同了。
当孩子刚出生的时候，我们总会寄予太多的期望。
而整个社会总归会是橄榄型的，不可能有那么多的天才，我们得承认自己孩子就是普通的。但是并不代表因为承认了这点，做父母的就可以懈怠了。
孩子的兴趣是需要扶持和培养的，还有三观要正确。
经常我们想的太过遥远了，连长大后学什么专业，从事什么职业都已经规划好了。就跟我们小时候，老师问长大要做什么啊，90%都是科学家，可最终呢？
还是每个阶段做好应该做的事情，未来怎么样谁又能知道呢，上大学前我都没想过要学计算机的，可最终还是干上IT了。
既然3岁前，那就好好玩，看看各种不同的文化和自然环境，每天在家看看绘本，至于什么时候会爬，什么时候会走，什么时候认识多少字，这些有那么重要吗？不就是早点晚点的事情。
现在在上爱尔惠母的亲子课，但是自从升级到音乐课后，大家普遍反馈不好。于是踏上了慢慢试课的旅程。
上周是试了小小运动馆，从头到底一个老师就让大家自己玩了，当中稍微指导下，还特别贵，400块一节课。
于是这周试一下美吉姆的课，我们试的是14-23个月的，这个跨度也太大了。
全程都是中英文进行授课的，一个老师，一个辅助。活动也挺多样的，但是因为孩子都跨度太大，导致有些活动对于一些孩子太简单，而且对于怯场的孩子没有很好的关心。
各个家长和孩子都没有任何交流，感觉大家都不认识的，而在爱尔惠母，因为孩子最大的年龄差距就1个月，所以基本还是很一致的，而且待的时间长了，各个家长和孩子之间会有很多的沟通帮助什么的。
想想试课的目的是为了小小球的感统训练，其实就是他现在有点胆小。现在看来没有什么课程是合适的，是不是应该从我们家长开始着手进行，多带出去走走看看，多跟哥哥姐姐一起玩玩。
北京植物园里的樱桃沟是两山之间的一个风景区，离门口非常远，风景不错。
<夹边沟记事>被誉为中国的<古拉格群岛>， 结果这书现在成了禁书了，而<古拉格群岛>还居然可以销售。
<樱桃沟夹事>是一个梦境中写的书的名字，还有封皮是土黄色的，其他详细的实在记不清楚了，所以想起很多东西我还是需要记录下来，不然以后可能都没得回忆了。
blog里放的可能都整理过的，这里放的基本都是想到什么就说什么的。
本来以为confluence这样的东西应该很好恢复，就一个程序一个数据库，迁移换个地方再导入重新启动就行了。 但是这次数据意外出现了问题，导致只能用MySQL备份的数据来进行恢复了，这样首先肯定是很多附件没有了。 首先是新装一个confluence，在页面中进行安装，刚开始出现server-id的部分，暂停安装，关闭confluence应用，修改confluence.cfg.xml 这个文件的confluence.setup.server.id这里的值跟你原先的保持一样。 要找原先的serverid就需要把原先的备份数据库导入到mysql中，取名为confluence， select * from BANDANA where BANDANAID=1; 就可以取得。 然后修改完confluence.cfg.xml 的server.id后我们继续启动confluence安装程序，在连接数据库的部分要写一个新的库，比如confluence_new， 然后db的用户名密码和原先一样。 这样就使用新库就安装完成了。 接下来就是关闭confluence进程，然后继续修改confluence.cfg.xml这个配置文件中hibernate.connection.url 这里的数据库地址到老的db（confluence）上。 然后我们再次进入mysql命令行，将confluence_new这个库里BANDANA表里的BANDANAID 1到4的内容全部update到老的db中。 我们再次启动confluence，这样就用上了原先备份的数据库内容了。 不过我实际过程中还多了一步，因为原先confluence和jira是互联的，而现在这2个都更换了IP重新部署了，而confluence我们又是用的jira的账号进行登录的，因此还要设置cwd_directory_attribute这个表里的数据。主要是attribute_name: user_encryption_method，attribute_name: application.name，attribute_name: application.password，attribute_name: crowd.server.url 这4条数据。 而如果你使用了confluence自己导出的备份，那是一个全量备份，那就只要安装好新的，然后导入就可以了，但是那个confluence数据的目录也是需要还原回去的。不然很多附件也是会丢失的。 所以所有新玩意第一次备份的时候一定要验证备份的可恢复性。切记切记！
已经很多场合说过普通运维在未来5年内是要消亡的言论。只有大型IT企业才会需要专职的运维，就跟网络工程师的消亡是一样的道理。 先看看运维对于一个公司的价值是在哪里。 成本： 一般而言运维是花钱的部门，控制成本自然是从多方面都要做。购买云服务和各种固定资产，一个合格的运维自然懂得最高性价比的东西，之前我们这些每年省下的钱招5个工程师，或者加20个服务器都有富余。 控制成本另外是减少产品成本，之前有过一个很简单的例子是，产品要求点播节目单是实时推送的，这个算出一个很大的天文数字来，但是如果我们改成5分钟推送一次，这样可以降低80%的费用，而且本来这个节目单的变更也不是非要实时的。除非你们家产品完全没有成本压力，不然很明显知道选哪个。 数据驱动：之前在做SNS的时候，会把每个广告位进行编号，总能发现一些位置的点击率就是比另外的高，而在带宽支出是一样的情况下，很明显推算出哪些是需要提高价格投放，哪些是降低价格，至于DSP这样的就另说了。 技术架构： 稳定，安全，高效，复用，冗余是运维要考虑的出发点，这个跟大部分开发的出发点是不一样的。 稳定的意思是说，这个东西是大家熟悉的，迭代过多年的，在高可用方面有成熟的方案。 之前我们有用redis要当存储，虽然redis本身有bgsave，那时候也没有redis cluster，哨兵浪费机器有点多，还有IP切换等问题，但是redis本身又不适合作为最终存储，但是开发人员为了要在99.9%请求要在2ms内返回，那就只能用这个，但是数据的安全性就必须要处理，那就得跟开发一起讨论了，最终讨论出来基于一致性hash的redis集群，一致性hash在redis客户端进行实现，每个key至少存放2份，同时加上redis node的监控（响应时间，内存剩余），这样这个系统在上线前我们基本就心中有底了。 效率 对于外面人来看这个就是救火的速度。但是对于内部来说一个是平时的演练，另外就是一个自动化的程度。这个一定是自己来做的，因为当平时没有故障的时候，这些东西是完全看不出的。 随着现代应用越来越复杂的趋势，要做好故障演练，benchmark这些是非常耗费资源和人力的。 安全 同效率一样，这个只有大公司才会重视的，当初创公司连业务都做不完谁会去关心这个呢，而且这两项都是需要花钱的。 安全一个是对外的安全，比如外部防火墙和入侵检测，DDOS这些。另外一个是内部的安全：账号密码管理，操作审计，备份安全等等。 同样这个也是平时根本看不出成绩，
close_wait真是一个让人崩溃的状态，常常只有几千个的时候就让服务器直接挂了。 可不这次又碰上了，报警说_close_wait_太多，查了一下是都是公网网卡那块_close_wait_ 通过tcp的4次挥手我们可以知道，close_wait_是发生在客户端往服务器端发送_FIN_请求后，客户端会把自己置为_finwait1, 而服务器返回给客户端后会把自己的状态置为_close_wait_，再等待一段时间后会发把自己置为_last_ack_ 理论上讲，_close_wait_的产生是由于程序意外中断导致的，但是原因可能是多种多样的。 用_netstat -s_也查看了下网络情况，因为这个是网络启动到现在的累积情况，所以需要对比之前5分钟的看，但是也没看出多少异常来。
266813 invalid SYN cookies received
7511 resets received for embryonic SYN_RECV sockets
3096 packets pruned from receive queue because of socket buffer overrun
11 ICMP packets dropped because they were out-of-window
603754 TCP sockets finished time wait in fast timer
12 time wait sockets recycled by time stamp
7082 packets rejects in established connections because of timestamp
890380 delayed acks sent
615 delayed acks further delayed because of locked socket
Quick ack mode was activated 161020 times
10129 times the listen queue of a socket overflowed
10129 SYNs to LISTEN sockets ignored
74494 packets directly queued to recvmsg prequeue.
29399 packets directly received from prequeue
20966540 packets header predicted
6813794 acknowledgments not containing data received
12672614 predicted acknowledgments
1 times recovered from packet loss due to fast retransmit
4237 times recovered from packet loss due to SACK data
42 bad SACKs received
Detected reordering 311 times using FACK
Detected reordering 56228 times using SACK
Detected reordering 35401 times using time stamp
683 congestion windows fully recovered
56047 congestion windows partially recovered using Hoe heuristic
TCPDSACKUndo: 19806
24593 congestion windows recovered after partial ack
5911 TCP data loss events
TCPLostRetransmit: 569
2 timeouts after reno fast retransmit
3830 timeouts after SACK recovery
1556 timeouts in loss state
60642 fast retransmits
6040 forward retransmits
17845 retransmits in slow start
79714 other TCP timeouts
493 sack retransmits failed
15031 packets collapsed in receive queue due to low socket buffer
160518 DSACKs sent for old packets
43 DSACKs sent for out of order packets
87404 DSACKs received
754 DSACKs for out of order packets received
3733 connections reset due to unexpected data
242941 connections reset due to early user close
10649 connections aborted due to timeout
TCPSACKDiscard: 1094
TCPDSACKIgnoredOld: 1384
TCPDSACKIgnoredNoUndo: 35778
TCPSpuriousRTOs: 103
TCPSackShifted: 21957
TCPSackMerged: 27204
TCPSackShiftFallback: 207287
TCPBacklogDrop: 1
TCPOFOQueue: 30173
TCPOFOMerge: 45
TCPChallengeACK: 21202
TCPSYNChallenge: 21096
TCPFromZeroWindowAdv: 117
TCPToZeroWindowAdv: 119
TCPWantZeroWindowAdv: 8861
然后认为是网卡队列堵了，因为netstat查看有很多_Recv-Q_，这个表明网卡接收队列堵了，于是就想着先优化一下tcp队列吧。那就优化下
net.ipv4.tcp_max_syn_backlog = 2000
net.core.netdev_max_backlog = 2000
net.ipv4.ip_local_port_range = 5000 65535
net.ipv4.tcp_max_tw_buckets = 5000
观察下效果好像是缓解了，但是看着并没有本质上解决。于是又看了下并发，也就2万左右，当初1台机器我们都可以抗20多万的并发呢，现在nginx怎么会抗不住呢，百思不得其解。 又看了下日志，发现这些请求都是https的相关请求，于是怀疑是ssl握手导致的，查看了当时cpu的状态，果然那个时候的cpu使用率都到了96%到97%了，这个明显是nginx响应不过来了，看了nginx的error log里很多stack traceback这样的错误信息，之前就一直以为是lua程序写的有问题。 既然找到了是https的问题，那就得优化下nginx关于tls部分的设置了。 ssl握手协议的时候RSA和ECDHE这2个算法开销会比较小，而RC4和MD5的开销会比较大。而默认ssl buffer size是16k，这样导致的结果当buffer比较小的情况下会继续等待满了16k才会返回，改成4k后会尽快的进行返回。
ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_buffer_size 4k;
ssl_session_tickets on;
ssl_stapling on;
ssl_stapling_verify on;