1234我最近考虑了关于方案设计中“估时”这块，觉得自己估时也不是很准。 做项目中最难的点且最有价值的点在于 ：1.自己没碰到过且需要自己去探索的地方。这个地方估算时间是最难的。2.想往前走，走着走着感觉“水“好深，但往回退 又会浪费很多时间。--来自同事金鹏的感触 为什么我估时总是不准确？时间观念首先，我觉得时间观念在估时过程中，起到的作用是至关重要的。一个时间观念强的人，会把估时当成一种承诺

CPU信息查询几个cpu more /proc/cpuinfo |grep “physical id”|uniq|wc -l 每个cpu是几核（假设cpu配置相同） more /proc/cpuinfo |grep “physical id”|grep “0”|wc -lcat /proc/cpuinfo | grep proces

参考资料 http://www.letuknowit.com/post/19.html http://www.letuknowit.com/post/22.html 操作方式需要先添加EPEL(Extra Packages for Enterprise Linux) repository，添加方法如下，请根据Centos的版本和CPU自行选择，如果不清楚如何查看，请参考《Linux查看系统信息常

现象 205.233上面，一个存放日志的表，数据积累了很多，删除该表后，发现数据占用情况没有发生变更。 1234567891011121314151617181920212223> show dbs;admin (empty)local 0.078GBlogservice 17.945GB> use logserviceswitched to db log

yjs2015-03-231234567主要问题有两个：1.首页请求没有缓存，用户过来的请求是动态地址，而首页又比较大，造成很大的流量2.定时刷新的请求，把所有的数据都返回了解决：1.首页开启GZIP2.将定时刷新的请求进行拆分 2015-03-25123456789通过分析日志，查找规律后发现：1.每天有大量无权限的首页请求2.流量异常的请求，有很大一部分是没有权限的请求3.流量从3.20日开

难以管理 脚本多，意味着业务也复杂，交错纵横的数据流都隐藏在脚本中，后期很不好查找定位。 而且脚本程序的代码质量普遍偏低，大多都是流水账式的编程。 另外，编写脚本时没有考虑到后期维护，没有增加一些调试功能，也会导致管理上的问题。 性能问题 脚本往往需要频繁更新数据库，而且脚本中经常为了简化代码，将业务功能通过复杂的sql来实现，这些写入操作会导致数据库堵塞，从而影响前端页面的访问速度。 一个很典型

常见流量问题GZIP压缩未开启 短线宝没有开启GZIP，返回的原始数据很大，开启后减少了80%的数据大小 缓存利用率低 比如短线宝的首页，很多内容针对所有用户都是相同的，但是每个用户来访问，都把整个页面重新返回了，页面html有4000多行，大小150K，这会造成非常多的流量 这种情况，可以动静拆分，对静态数据做好缓存 返回冗余数据 还是短线宝，请求精品内参时，将文章列表和每篇文章的具体数据都返回

场景 有个项目为了安全考虑，采用post方式访问了一个静态html文件，服务器返回405 原因访问静态文件的时候只能使用GET方式，不能使用POST，因此在nginx的返回信息中，在0.6.33版以后就增加了这么一个405错误状态码，意思就是，你不能用POST方式来请求静态文件，错了，要换个别的方法。 解决方案 将405设置为200 在nginx配置中增加：error_page 405 =

注意事项1.该内容仅针对集体户口、单人贷款的情况，非集体户口和夫妻共同贷款会有所差异。 2.建议去之前，先给每个机构打个电话，确认下当天是否可以办理，需要哪些材料，避免到了那边才发现缺少东西。 3.如果是骑电瓶车，建议在每个地点都充充电(我的电瓶车不大好，最后没电了，余杭那边没找到充电的地方，只能推回来，昨天晚上还下大雨) 4.出门前看下天气预报，选个没雨的日子去办理资料 准备工作1.提前一周让人

组员工作安排忙的时候，能够协调人员分担压力(这和专人专职冲突)闲的时候，能够穿插任务避免浪费(这需要你维护一个待完成的需求池) 第一种：以 5 个人的小组为例，包含一个组长+4 个组员，那么可以分为三部分：组长：负责项目方案的设计把关、质量把关，以及搜集和发现团队现存的问题和改进意见，组织讨论，确定具体的改进方案。3 个产品开发人员：负责当前产品需求的实现1 个基础建设人员：和组长一起进行团队改进