很小的时候，肯定是在10岁以前，在类似《读者》的一个刊物上看到：（以下内容引自百度百科）“有一个大王叫犹太王大卫。某一天做了一个梦，梦中梦见一个神仙。神仙告诉犹太王一个方法，无论是多么的艰难都会顺利的度过；无论怎么富有和有权利也不会骄傲自负。结果梦醒后犹太王想不起来神仙告诉他的方法，他就召集大臣悬赏，谁要是知道他梦中的方法他就赏这个人一辈子的荣华富贵。结果大臣们想个好几天终于给犹太王一个答案，那就是：这也会过去。之后犹太王大卫就把这句话刻在了戒指上，来警示自己 。”
后来想起这句话，总觉得应该是翻译过来的，而不是本土自制的心灵鸡汤；但一直也没有找到英文原文。今天无意中从生活大爆炸里面看到，This Too Shall Pass，解决了多年来心头的一个疑惑。
某同事体检，留了QQ邮箱，体检结果寄到了邮箱里。
现在他需要把这个pdf文件交给另外的人，麻烦在于这个pdf在QQ邮箱里的preview是能看到的，但是下载下来是无法用Adobe打开。
上网搜了一下，倒的确有在线修复工具。尝试修复，无果。
后来想到firefox不是也内置一个pdf.js做PDF的在线查看么。。。于是用firefox打开之，结果还不错，5页的PDF，后四页都正确解析出来了，第一页是空白；所幸第一页就是这个体检机构的封皮，于是重新打印到PDF文件后面的4页生成新文件，搞定
上次研究完 HAProxy，觉得这东西搭配 Postfix 挺好，就安排给运维了，结果运维同学反馈，加持了 HAProxy 以后，返回 220 欢迎信息时间显著变长，于是昨天就抽时间和运维一起分析这个事儿
我的第一反应是 Postfix 处理 Proxy Protocol 有延时，比如反向DNS查询什么的，于是首先在 Postfix 服务器上执行 tcpdump
观察到，当客户端连接 HAProxy 之后，立即 HAProxy 就和 Postfix 完成了3WHS，然后足足等了 3 秒，才从 HAProxy 发来了 "PROXY X.X.X.X XXXX"
现在可确认延时发生在 HAProxy 上，接着去 HAProxy 机器上 strace -tt HAProxy进程
观察到，当完成和后台 Postfix 的 3WHS 之后，的确就立即把 "PROXY X.X.X.X ... "发送了，但是等了3秒，才recvfrom后面的 220
问题出在哪里呢？？仔细看传送"PROXY X.X.X.X ..."的系统调用，原来是用的 send() syscall，而且，它使用了 MSG_MORE 这个参数... (不明白什么是 TCP_CORK 的同学可自行搜索，HAProxy 在这里使用 MSG_MORE 是很有道理的)
但为什么这个延时长达3秒实在理解不能，在我自己的机器上试了一下，是200ms，查看 sysctl 里面的 tcp 设置也没有头绪，对于这种古老的RHEL4服务器只能出大招了：因为这个HAProxy是为SMTP代理专用的，直接修改HAProxy源码，把MSG_MORE注释变成0就一切正常了
http://blog.netzhou.net/
下午和KCN领导聊天的时候随口提到这个事情，不完全是吐槽
总之，目前搜狐的技术委员会评出的3.1，比某度的某些T5还要靠谱一些。这个给业务在某些程度上造成了困扰，希望这个制度能越来越好，并且技术委员会能在2014年发挥除了考核之外，更大的作用
以当下的苛刻要求而言，在业务部门而不是研发部门的，年过30的同学，想在这条道路上精进到4.x，是一件很困难的事情——除非你做出一个牛逼的平台产品出来
目前搜狐技术委员会的标准，是：针对一个互联网服务需要的各项技术要求，你能带来什么价值我严肃的思索了一下，当初我从eyou跳槽来搜狐的话，3.1或许能符合要求，3.2是绝对达不到标准的（应聘运维可能还能有4.x的机会）
所以，就只能和BAT竞争毕业生了，同时要给很好的机会，很好的导师，很好的环境，来帮助其成长
附：我自己觉得自己在技术上做得比较得意的事情
最遗憾的事情，是进搜狐后，对运维的认识不够，很久很久以后，才形成认识和方法；否则很多事情能做得更好
企业电子邮件的未来到底是被一个新工具替代？还是邮件的自我进化？Contatta 是后面这条道路的一种尝试
注意到这个公司首先是看到了它制作的一个专题，觉得设计挺用心。于是好奇去网站上看了一眼，Demo 还算吸引人；最有意思的还是三个创始人完全没有计算机工程背景——2名销售+1名设计师，这种完全不符合一般认知的团队，很期待能给市场带来新的活力。
它制作的专题见下：
Courtesy of: Contatta
我们是一个致力于用云计算技术改变现有企业IT模式的团队，希望您能认可这个技术趋势，让我们一起为改变世界而努力。当前我们专注于企业基础办公领域，提供SaaS模式的企业邮箱 产品，以及围绕邮箱的扩展增值服务。
我们在服务器端使用的主要的开发语言是 Python，技术工作包括：技术的挑战是，应对复杂的IDC和网络环境，如何构建出，并运维好一套分布式高可用的系统。电子邮件是现代企业办公的最最最基础组件，用户无法容忍哪怕是非常短暂的服务不可用， 这给我们的技术工作带来了诸多要求和限制条件，亦是艰苦工作背后的乐趣和价值体现。
在生产环境中，Load Balancer 相当重要。常见硬件有 F5，软件有 LVS，或者更偏应用层的 HAProxy。
但实际运用中，怎么把 source ip/port 传递给后端的 real server 是一个大问题。因为realserver通常是需要这些信息用来记日志，或者安全防护策略应用之类。。。
如果是 F5，需要 real server 把自己的 default gateway 指向过去；如果是 LVS/HAProxy 也类似，需要LB服务器打开 TPROXY 内核选项，同时 realserver 有网段的限制。
上述的方案虽然透明，但是对网络结构有特殊要求，所以后来 HAProxy 的作者提出了 Proxy Protocol
现在至少 Postfix 2.10，甚至 Haraka 都能支持这个协议了。
HAProxy 很值得尝试
上周日，经纬的熊飞凑了一群做SaaS toB业务的老板们喝茶。
神州鹰的叶总对自己产品很有信心，他们不用直销，号称3000家渠道，按照他的说法，直接找老板上门演示，都不用介绍产品功能，老板自己就能琢磨出这个工具能给日常管理带来哪些变化
北森的纪总则必须依赖直销。因为他们的产品比较复杂，必须了解客户的需求后，才能告诉客户哪些模块是他所需要的。最终还是要走到解决方案的路上，他最后这么说。销售必须理解客户的痛点，否则说服不了客户。
====
采取什么样的营销模式，和产品性质息息相关，也是商业模式中的重要组成部分。周教主所说的产品模式、用户模式、推广模式、收入模式是一环环紧密相连的。
回想最近3年，最大的心得是要首先做好团队定位和人员盘点，然后才是运营KPI的正确制定和执行
本站的feed
最新评论