|
|
And so my end conclusion in all of this is: if you want autonomy, and the ability to own and control your own domain and projects – it is your job to push information and build trust with your team members.
In other words, you need to learn and do the following:
Follow through. Do what you say and consistently deliver on your commitments.
Proactively communicate when a task takes you longer than you thought, and why.
Improve your communication skills. In order for others to hear you, sometimes you have to hone the way you deliver your message.
Volunteer information and make an effort to explain vague or hard to understand ideas and concepts. Make an effort to share the details of your decisions and diversions. This is also important when you make mistakes – letting others know before they figure out on their own will show ownership of the situation and can prevent misunderstandings later.
Be forthright and authentic with your feelings. Even when you may hold a contrary opinion communicate your thoughts (respectfully and with tact).
Don’t talk behind the backs of others. It is very difficult to build trust if someone knows that you will say something negative about your boss, the company leadership, or another coworker.
Be objective and neutral in difficult situations. Learn how to be calm under pressure and act as a diplomat resolving conflicts instead of causing them.
Show consistency in your behavior. Not just in follow through but by eliminating any double standards that may exist.
Learn to trust them. This is one of the hardest ones, but trust is a two-way street. Giving others the benefit of the doubt and learning how to work with them is essential to a strong mutual working relationship.
In turn hopefully you have a good manager that will be able to ask you good questions and take the time to understand your contributions. And if that is not your situation, then make sure you are sharing information with those around you; such as your peers, your boss, and other stakeholders.
Good leadership is keeping everyone on the same page, and if you want independence, it is on you to make sure people know what you are contributing.
摘自 The Paradox of Autonomy and Recognition – thoughts on trust and merit in software team culture
- 在production环境上，使用也要小心，因为该pending timeout的DDL enqueue会阻塞后来的DML操作。 http://t.cn/zTTrvPb DDL_LOCK_TIMEOUT in 11g. 原理是, Oracle的锁处理是一种排队机制, 排队是分先后的, 排在队列前面的操作会阻塞排在后面的操作, 也即当DDL被阻塞时, DDL操作本身会阻塞一批后续的DML操作, 这可能会给系统带来很大的负面风险.
- http://t.cn/zlZDD0w 也谈大公司病1——正确是最大的错误,1. 做正确的事比正确的做事更重要, 但是, 大公司中存在太多的正确, 当公司倡导的n种正确出现冲突，哪一种更正确? 2. 流程与效率的冲突问题, 3. 正确延误了学习，长期看带来能力降低; 正确延误了创新，阻碍了变革。
- Being able to recover quickly from failure is more important than having failures less often. 也即MTTR is more important than MTBF ( 相对于更少的出现故障来讲, 可以快速的从故障中恢复过来, 要更加重要). 在此文中, Eric Brewer有个补充, “由于故障的复杂度在不断提高,MTTR显得更加重要了”. 链接: mttr-mtbf-for-most-types-of-f/
- http://t.cn/zjQFy7M Dare Obasanjo讨论 MSN Spaces遇到的扩展性问题时说, 在你还是个创业公司时, 不要花费大量的时间与精力去考虑达到100万用户后的扩展性问题, 当你过早的考虑这些问题时, 或限制你提供新的功能/特性的效率. 记住, 哪怕是Google/Microsoft这些大鳄, 也会遭遇扩展性的问题.
- http://t.cn/zTTt4Uq 在努力基于几个好的创意,好的想法做出用户喜欢的产品,在业务的规模没有达到一定的规模之前,不用太多的考虑(不是不考虑)扩展性问题,不用太多的考虑99.999%的可用性, 扩展性的问题也好,可用性的问题也好,都是一个关于投入产出的平衡的问题.
- http://t.cn/zTONtYH Todd Hoff对Eric Brewer在InfoQ的演讲NoSQL: Past, Present, Future（http://t.cn/zjOJLAL） 的解读，不过，我觉得他关于此问题的理解还是偏于肤浅，不同方案的选择是基于经济的理由。对于银行的业务，由于通讯的问题，复式记账、审计、坏账准备金、风险管理都是为弱一致性准备的
- http://t.cn/zTjVK8O 大规模分布式计算的几个新的谬论，1. 实例是免费的（对应于EC2的节点），2.实例名的身份有含义（节点的名称会虚化），3.Map/Reduce是解决问题的灵丹妙药。传统分布式系统的8大谬论请参考此链接，http://t.cn/zTjVK8W
- http://t.cn/zTCP3zf ‘Small Data’ Enabled Prediction of Obama’s Win, Say Economists 使用”小数据”来进行总统竞选预测,结果与”大数据”相差不大,哈哈.
- http://t.cn/zTCP01e Eventual Consistency Today: Limitations, Extensions, and Beyond By Peter Bailis, Ali Ghodsi, Peter Bailis从源头上梳理最终一致性的概念,从概念的提出到概念现阶段的理解,如何设计并度量系统最终一致性的程度,如何在不同的场景下选择不同的最终一致性方案.
- http://t.cn/zTXjLJl Continuent Tungsten Replicator Is Now 100% Open Source 数据库复制做的非常成功的Continuent Tungsten Replicator宣布完全开源,也即可以完全免费的通过它来获取Oracle内部的变更了. 这是个好消息. Tungsten是目前MySQL社区做的最好的跨数据库做同步做的最好的开源产品了, 支持MySQL/Oracle/SQL Server之间的数据准实时的交互同步.
- http://t.cn/zTXlXMd BrainTree的高可用架构, 如何通过队列缓解短时间的系统维护造成的问题,那几页PPT很有意思, slide-31 到slide-68都是利用此方案来进行系统的维护,包含代码发布/数据库迁移升级切换. 虽然,很多人在讨论通过队列解决系统的削峰填谷作用,如BrainTree这样实践的确实不多见.
- http://t.cn/zTXl2mE BrainTree 为什么选择使用postgreSQL替代MySQL:Schema Change的代价;为什么选择使用Pacemaker+PG的Sync Replication来替代DRBD:切换时间,DRBD复制对系统复杂度的要求,每次升级内核都需要重编译内核模块,每次切换都涉及文件系统的umount/mount,文件系统的风险不可控.
- http://t.cn/zTX0kpC BrainTree 如何配置数据库的自动Failover,1. 数据库是PostGreSQL,2. 同步方式为,同机房Sync,跨机房Async,3.禁止来回切换,也即只允许单向切到Sync备库,4.当Pacemaker不能确定可以自动切时,自动冻结操作,此时需要人工介入.在推向Prod前后,做了大量的测试与验证工作.
http://t.cn/zT6Wun1 http://t.cn/zT6Wun3 GroupOn使用MySQL的一点经验:1. slow log的切换处理,2. 使用playback在Slave上重放操作,以warm up备库的Buffer Pool.
http://t.cn/zT6JusR 根据数据的价值来选择匹配的数据存储成本, 数据有三个维度(新鲜度,访问频率,商业价值,即:Recency/Frequency/Monetization), 根据这三个维度去评估存储的数据,并选择对应的存储设备(Flash/SAS Disk/Sata Disk; Local/SAN).
http://t.cn/zT6G2jE 可扩展系统设计,常见技术:1.负载均衡,各节点无状态,2.数据分区(DB Sharding),3.批量处理(M/R),4.缓存(静态数据/动态数据/连接池/重复计算),都权衡一定的一致性损失,5.异步处理,与业务解耦组合使用,一般都涉及使用队列(Queue),6. 关注并发(Shared Mutable State,本文没有)
就@bluedavy 的一条微博消息,我自己的一点看法:规模非常大的时候,相对于小规模场景,主要的技术差异也就拆分(partitioning/sharding)加上运维自动化, 而实际上,小规模业务也是可以去做运维自动化的. 因此, 除了不怎么需要做拆分(业务层/数据库层)外,技术差异是很小的,就在于你自己的追求了. 【说你呢】哈哈
当然，规模大了，如何提高运维效率、发布部署效率，如何切实的减少、控制系统依赖的规模，如何有效的控制故障的范围与等级，都会有更多的挑战，而这些内容，在追求完美的工程师来讲，规模较小时也是可以做较多的尝试与实践的，比如远比淘宝规模较小的Etsy在这方面就有较多也较深入的经验。
技术是为场景服务的，但是，不是等到有场景才有技术，而是需要在场景未到之时，先从其它渠道尽可能的了解到相关的技术，别人在此过程中曾经遭遇的痛与坑，尽量做到不要重复的遇到别人曾经遭遇的同样的痛与坑。希望 @bluedavy 毕玄同学可以深入的分享下自己遭遇的那些痛与坑
我周日在ACOUG上进行分享的PPT，从方法论的角度讨论Oralce数据库的优化，优化的关键点还是在于如何定位瓶颈资源（Contention），并通过Scale Up（优化）或Scale out（拆分）的方式进行缓解：”Oracle 性能优化.pptx” http://t.cn/zT6PcMw
我4月18日在DTCC数据库大会的演讲：”CAP 理论与实践.pptx”，主要观点：1. 过去的所谓CAP，Pick Two过于简单粗暴，不合理，2. 现实的情况是，根据业务的数据的含金量确定可接受的C，再尽可能提高A，类似于信息展示类的会更多的选择牺牲C，而资金类则保全C http://t.cn/zTxf7wO
http://t.cn/zTVs1Ll 如何通过RMAN将Oracle的数据库备份到Amazon S3，其实备份到其它的类似的云存储上，也可以考虑类似的处理方式。 Amazon AWS提供的白皮书，http://t.cn/zTVs1Lj
http://t.cn/zTcJYvz http://t.cn/zTcMuJa http://t.cn/zTcJYvZ 如何基于Unreliable Cloud设计Reliable System. 1. 识别应用的有状态部分与无状态部分，2.使用真正的分布式的数据存储来对有状态部分进行冗余处理，3.确保冗余处在隔离的故障区域，4.识别故障依赖并降低故障影响,5.将服务细化并隔离Complexity + Scale => Reduced Reliability + Increased Chance of catastrophic failures，The higher the number of dependent components => the lower the overall availability and the bigger the impact of failure，http://t.cn/zTcMuJa 这两句话值得细细思考。
“The marginal cost of reliable hardware is linear while the marginal cost of reliable software is zero.” 可靠硬件的边际成本是线性的，而可靠软件的边际成本为零。也即：在一定的规模下，可靠的软件相对于可靠的硬件会更加便宜。http://t.cn/zTcIsx3
这篇文章中，我同意关于Reliable/UnReliable;Software/Hardware的比较，以及可能的边际成本比较，对于其所举的例子持保留态度。
其实，目前的Reliable Software也是通过冗余(Replication)来实现Reliable，就如同Reliable Hardware更多是通过Pair（双份）来实现冗余，其它都是软件控制//@jametong: 这篇文章中，我同意关于Reliable/UnReliable;Software/Hardware的比较，以及可能的边际成本比较，对于其所举的例子持保留态度。
几篇关于Performance与Scalability的文章，http://t.cn/zTc4oZm http://t.cn/zTc4oZu http://t.cn/zTc4oZ3 可以通过优化减少资源使用或提供更多资源来增加可扩展性，前提是你的架构允许使用更多的资源，也即并行化处理请求的能力，这通常来自于限制完全并行化能力的数据库，原理即Amdahl定律
http://t.cn/zTtDU3Z Quora的创始人Adam D’Angelo讨论为什么Quora使用MySQL而不是NoSQL，1.如果支持Sharding的话，MySQL的扩展性并不差，2.NoSQL并不像宣称的那么可扩展，稳定性还有待改进，3.主数据存储不能冒太大风险,4.不拆分，MySQL的扩展性也还好，5.可通过中间层解决分区两年时间观察下来: 发现搞传统RDBMS或一直在RDBMS上做工具和产品的人还是一样的敏感，总是试图去寻找看看谁又在说“不用NoSQL的理由了”，听者从中得到安慰。在如今RDBMS、NoSQL边界越来越模糊，科研、工程技术人员都钻破头想着如何把两者融合的现实中，总有人忧虑自己会的东西会不会过时!怎会过时呢？
回复@zhh-2009:两者在融合，只是从两个不同的方向在往中间努力。1. NoSQL在考虑增加一定的ACID支持，由于大规模Scalability的需要，目前主要还是基于单Sharding维度的ACD整合，2. 传统RDBMS在整合部分NoSQL的理念，a. pg支持Schema Free，b.M支持基于引擎的调用，c.简化Sharding管理的大量工具
回复@zhh-2009:是的，这几年很多存储引擎层的改进，都出现在写优化算法的改进上，从这个角度看，其实我更加看好TukoDB与Acunu的改进， LSM-Tree对读是很不友好的，同时，Merge对资源的浪费也是比较严重的，性能与吞吐量也会由于Merge的存在无法做到持久稳定的性能，这对于生产环境的容量规划是个问题
http://t.cn/zTUHTum 如何禁用Oracle 11g的新的xml格式的listener.log以及如何指定listener.log的位置。对于我这种古董级别的人有用处，哈哈。
http://t.cn/zYexkvH 如何利用Thread Pool提升MySQL系统的吞吐量，参造交通系统的流量控制，以及排队论的基本知识介绍如何通过Thread Pool来提升系统的吞吐量，在没有Thread Pool的情况下，系统的用户到达率会不断增加，而从不断增加对系统关键共享资源（CPU、内存）的占用，损害到整体的吞吐量。
新浪的面试题：用户更新数据时，修改了database数据的同时需要修改memcache，为什么facebook这篇文章里面推荐用delete key的方法来更新cache，而不是直接update？
我的理解,两个关键点:
1. Update处理，由于Key不会从缓存中消除掉，如果由于程序重启或其它原因导致中断，则会导致缓存中的数据必须到过期(Evicted)，都会是Stale的数据，可以通过其它的机制来进行补偿，但是，代价也不低。//@TimYang: 估计用update的人更多一些，ugc类型产品，只要不是共享资源修改，通常也没问题
2. 并发问题处理, 关键还是Delete操作是幂等的，并发问题容易解决；Update操作是带状态的，如何做好并发控制是个难题. 所以通过Delete＋Select的PutKey更加容易控制，复杂度也更低。关于更新缓存与数据库更新不一致的问题，DELETE与Update Cache，需要考虑补偿方案来解决。
3. @一乐 同学跟我说,Memcache的Delete操作有一个Holdoff功能,可以更好的控制Cache处理的并发问题.
http://t.cn/zTXSeHC 关于Message系统的简要介绍,Message的作用(性能/解耦合/扩展性/成本与高可用),消息处理的模式(路由规则/是否持久化/消息转换协议),常见消息系统的简要实现与特性,消息系统的功能需求的总结,消息系统的运维需求(持久化/高可用/管理特性),常见消息系统在不同场景下的性能比较.与此博客文章,对照阅读: http://t.cn/zTXowBV 1.Brokers perform much better with bigger messages, 2. ZeroMQ is a perfect message dispatcher among processes,3. Except for big messages, RabbitMQ seems to be the best, 4. 对于较小的消息,时间被消耗在processing上,而不是I/O上.
|
|
