公司环境业绩的信息披露可以成为提高中国公司声誉的一条重要途径。约翰•艾尔金顿和乔迪•索普解释了其中的理由。

中国也许到了编制“可持续发展”和“非财务”报告的时候了，即向社会披露公司在社会、经济和环境方面的管理与业绩。最近发生的与产品质量有关的丑闻，例如在牛奶中掺入三聚氰胺，是采纳这一做法的重要原因。在当今的全球经济中，少数公司的错误会使很多公司的市场前景受到影响。

尽管编制可持续发展报告在全球实行约20年了，但是对中国而言还是新生事物，中国第一份可持续发展报告是壳牌中国于1999年发布的。不过，此类报告的数量增长迅速，2006年有18家中国公司发布了可持续发展报告。

那么，中国如何才能迎头赶上？15年来，SustainAbility“全球报告”项目一年两次公布可持续发展报告的调查结果，对全球各大公司披露有关可持续发展的管理与业绩方面的信息进行评估。从全球来看，可持续发展报告的数量获得了巨大的增长，2007年公布了近3,000份报告。而且，这些报告越来越多地来自新兴市场。1998年亚洲、非洲和拉美只公布了少数几份报告，但到了2007年，巴西、中国、印度和南非等国家公布的报告数量占到全球总数近10%。在巴西，可持续发展报告呈指数级增长， 2007年公布了约80份报告，是五年前的三倍。中国的报告数量看来也开始激增，增速甚至比巴西更快。

SustainAbility已将其“全球报告者评比”项目的工作重心从广泛的国际调查转到探索具体的问题、行业和国家，这样做的部分原因是出于出现上述变化的结果。我们依据新的思路首次为巴西可持续发展基金会撰写报告，对巴西10家大型公司的可持续发展报告的质量进行了评估，报告的标题是《通往可信之路》。

显然，《通往可信之路》的结论不能直接应用于中国，原因是编制可持续发展报告背后的驱动力取决于不同国家的背景。例如，巴西公布可持续发展报告是由不同的问题推动的，包括股市的透明度要求导致越来越多的公司曝光，以及可持续发展指数的出现，如圣保罗证券交易所的可持续发展指数（ISE）。另外两个因素是全球报告倡议组织（GRI）和来自非政府组织的压力。在中国，尽管GRI具有重大的影响力，但政府是鼓励中国公司肩负企业社会责任（CSR）的主要推手。实际上，中国发布可持续发展报告的公司依然多数是国营企业。

尽管如此，《通往可信之路》为引入可持续发展报告的其他国家提供了有关最佳实践和潜在缺陷方面的借鉴。尽管巴西可持续发展报告在评估中平均得分低，为47%，但这和我们2006年国际调查计算的全球平均得分57%相距并不太远。然而，在我们的巴西调查中，顶级公司之间依然存在明显的差距，Natura（一个大型的化妆品公司）的得分是54%，而2006年英国电讯公司获得的全球最高得分是80%。巴西顶级公司仍然落后全球顶级公司三四年。

造成这种差距的原因是什么？首先，全球顶级公司更善于把报告内容集中在“实质性”问题上，即那些与公司影响不相称的环境和社会问题上，无论是正面的还是负面的。巴西的可持续发展报告倾向于报告过多的信息而未考虑问题的轻重缓急。例如，我们分析了十份报告，平均长达161页，简直是浪费纸张。

此外，尽管巴西报告者善于清楚地说明他们致力于可持续发展的义务和能力，但是当描述执行这一远景的制度或以一种有意义的方式披露业绩时就差远了。这表明，对于巴西的企业而言，可持续发展报告依然是商业外的企业社会责任考虑，而非本身就是商业的一个组成部分。

最后，巴西公司的首要挑战（这一点已在我们的报告标题中体现），是如何让读者认为可持续发展报告诚实可信，表明真正致力于可持续发展。在巴西这种“可信度鸿沟”很大，而且与以下因素有关：普遍倾向于报喜不报忧；缺乏硬性的指标和商业目标；在报告中缺乏可信的利益相关方的声音；领导层缺乏真正的责任感。

根据这些发现推断，我们对期望开始编制可持续发展报告或改善其现有编制方法的中国公司提出三个建议：首先，“更少就是更多”。尽管可以理解报告者希望确保读者获得感兴趣的所有信息，但一份承载过多信息的可持续发展报告实际上有碍于读者的理解。相反地，报告应该确定最重要的问题（通常不超过四五个），并集中在这些问题上。

其次，尽管提供企业赠予和慈善方面的信息是有用的，但展示如何把可持续发展切实整合到中长期商业活动中，最终会更加有说服力和吸引力。而且，这将使你的公司在这方面独占鳌头。

最后，不要害怕报告挑战、失败和困境。利益相关方知道这些都会存在，因而对来自执行公司可持续发展远景的挑战作出诚实的说明，才能具有基本的可信度。如果报告未能提到这些明显困难，利益相关方会想知道还隐瞒了别的什么。其他提高信任度的因素包括：领导层具有真正的责任感（一封高层管理者发出的具有激励性的信函通常可以体现这一点）；把相关利益方的意见纳入其中；使用定量指标和目标。

对诸如巴西和中国的公司而言，这些建议具有挑战性，使得通往信任度的道路漫长而坎坷。然而，对于在可持续发展议程中渴望成为领导者的公司而言，建立来自社会的信任和支持乃是必由之路。

 

约翰·艾尔金顿是SustainAbility（www.sustainability.com）及Volans（www.volans.com）的联合创始人。

乔迪·索普，SustainAbility“新兴经济体项目”经理。

《通往可信之路》可在www.sustainability.com/roadtocredibility获得。

首页图片由romeo摄

Shared by 车东
原始日志非常重要，AWStats统计还是可以考虑和Google analytics结合使用的 :)

一 从何开始？

2006年10月，我和tiny创立银杏咨询，开始提供技术咨询服务。到现在，已经2年多了。时间过的真快！

这2年中，我们逐渐开始了站内搜索SAAS服务 ，但是咨询的服务也仍然在做。积累了2年，见过了太多正常的，古怪的，常见的，重复的，白痴的问题，现在，我打算开始慢慢的写出来，给别人参考。

当然，惯例声明。本文所述一切情况，并不来源于某个特定的团体或公司，是我们2年工作经历的组合，也就不用猜测到底是谁了。万一有雷同绝对巧合:D

记得我跟Fenng聊到过，写技术，尤其是优化和架构相关的文章，总显的很无聊。因为懂的人不说也懂，不懂的说了还不懂。新手的php程序员们不分场合的迷恋模版和MVC，而全然不知其所以然。所以后来我那个《让你的网站快100倍》，就没有继续写下去了。还是跟着实际的案例来看，会比较有趣一点，你说呢？

可以说，我们处在一个非常幸运的行业中，因为这个行业发展的太快了，人才缺口实在太大，大到历史上任何行业都没有过的程度。很多公司甚至糟糕到了没办法判断一个人是否能够胜任的地步了。某个公司的创始人跟我说，我们最大的问题是，根本没办法鉴别招聘来的这个程序员是高手还是忽悠。

这就是我们面临的情况。无数的新手，无数的忽悠，就这么草草上阵，开始为无数伟大的构想和商业模型搭建基础。如果不伟大的项目还好，早早就死掉了，也没有后面的问题了。伟大的项目，就会突然碰到瓶颈，这时候，大家都傻了。

我们的客户往往就是这类，他们是伟大的项目，所以他们碰上麻烦了。

“好了，咱们从何开始呢？”，会议桌对面的客户满脸的痛苦，想了半天，说出来这么句话。

我和tiny互相对视了一下，说：“就从你最头疼，影响最大的地方开始吧”。

这是一个媒体网站。按道理来说，媒体网站不大应该碰上性能问题，媒体网站更新量往往并不大，访问量也不大，但是人群比较集中，价值也比较高。这是网站里面活的最潇洒的一类公司，他们用数量小，价值高的pv获得可观的广告收入。对于硬件投入也比较舍得。但是现实总是这么荒唐，这种从来不愁钱的网站，碰上的问题最多。

他们最头疼的问题，就是网站会突然挂掉。但是找不到原因。

好吧，就从这里开始。

背景资料：本网站用java+jsp开发的。基于某古怪的架构(架构的古怪之处随后慢慢说)，每天更新量只有几十篇文章。访问量在百万以下的级别。没什么交互。

看起来很简单？清点一下系统拓扑图可不得了，竟然有10多台机器趴在机房里!而且还使用了CDN。饶是如此，仍然摆脱不了3天一小死，5天一大死的噩梦。

我们开始的方法很简单。查log。我们希望通过分析访问log，来获得系统各部分的负载状况，从而进行分析，找出薄弱环节。

log呢？竟然所有的服务器都没有记录log。

很多人认为，记录log会消耗更多的资源。其实并非如此，如果log非常大，比如几个G，确实会让写入的时候变得有一些慢。但是大部分情况下，如果定时清理，或是做了切分，不应该对系统性能造成什么影响。

平时不记录log是可以的，但是很多情况就错过了，将来需要回溯寻找问题的时候，就没有了依据。这很糟糕。google analytics很好，但是它是用来分析统计情况的，不是用来寻找系统问题的。你完全可以用google analytics来代替awstat之类的分析软件，但绝对不能替代原始的log。

针对这个客户的情况，我们记录了几种log。

1 java application server (tomcat/...) 的access log 和error log
2 apache 的access log和error log
3 mysql slow query
4 sar 记录系统活动
5 vmstat 状态 ，没什么现成的工具，我写了个脚本，供参考。

采集这些数据就可以进行初步分析了，修改好了所有配置，部署好了所需要的脚本，剩下的就是等待了。

等待出问题。

我心里偷偷的想，如果客户知道我们从这一天开始盼望着出问题，会不会恨我们.....

There is significant portion of customers which are still using MyISAM when they come to us, so one of the big questions is when it is feasible to move to Innodb and when staying on MyISAM is preferred ?

I generally prefer to see Innodb as the main storage engine because it makes life much simpler in the end for most users - you do not get to deal with recovering tables on the crash or partially executed statements. Table locks is no more problem, hot backups are easy, though there are some important things which we have to consider on case by case basics before recommending the move.

Is MyISAM used as default or as a choice ? This is the most important question to ask upfront. Sometimes MyISAM is there just because it is default, in other cases this is deliberate choice with system being optimized to deal with MyISAM limits, for example there is a dedicated slave available for all long reporting queries. In case MyISAM was chosen not just happened to be it is important to build the good argument to suggest Innodb.

Application Readiness Application should be ready to work with Innodb, for example be ready to deal with deadlocks which can happen with Innodb even if you do not use transactions, but which are not existent with MyISAM. QA has to be performed as part of the move.

Performance Innodb has a lot to offer in terms of performance - Performance benefits and drawbacks. On the benefits side we usually see clustering by primary key, caching data, higher concurrency, background flushes while on the drawbacks side we see significantly large table size (especially if data size is close to memory size), generally slower writes, slower blob handling, concurrency issues, problems dealing with very large number of tables, slow data load and ALTER TABLE and others. Another big one is COUNT(*) without where clause which is often the show stopper for them move until it is worked around.

Operations What is good for MyISAM kills Innodb, such as copying binary tables between the servers. It is important the team understands Innodb and knows how to handle it, or be able to learn it. It is also important to adjust processes as required to work with Innodb. For example binary copy of one of the databases from the Slave to the dev envinronment works great for MyISAM but does not work with Innodb. Backup tools like “mysqlhotcopy” does not work etc. Note Performance also affects Operations aspects a lot - for example using mysqldump as a backup may well work for MyISAM but will start taking way too much time to do restore for Innodb. On large scale installations mysqldump does not work anyway but it may still work for you when you’re running MyISAM but instantly break upon upgrading to Innodb.

Features The MyISAM features which forbid moving to Innodb are typically Full Text Search and RTREE indexes/GIS with Full Text being much more common. There are workarounds for both of them, including dedicated MyISAM slave or shadow table but it is important to consider them.

How about Mixing Storage Engines ? Sure you can mix storage engines but I suggest you doing is wisely. It complicates operations tasks (backups, balancing, performance analyzes) as well as it exercises not so common paths in the MySQL server - in particular Optimizer may have harder time because costs between storage engines may not be well balanced or replication of mixed table types which is quite complicated.

I prefer to pick one storage engine (typically Innodb) and when use other tables when it really gives substantial gains. I would not switch table to MyISAM because it gives 5% performance improvement but I can perfectly use MyISAM (or Archive) for logging.

Innodb Needs Tuning As a final note about MyISAM to Innodb migration I should mention about Innodb tuning. Innodb needs tuning. Really. MyISAM for many applications can work well with defaults. I’ve seen hundreds of GB databases ran with MyISAM with default settings and it worked reasonably. Innodb needs resources and it will not work well with defaults a lot. Tuning MyISAM from defaults rarely gives more than 2-3 times gain while it can be as much as 10-50 times for Innodb tables in particular for write intensive workloads. Check here for details.

---

Entry posted by peter | 18 comments

Add to: | | | |

This presentation illustrates how one can scale EXISTING JEE application and deploy it on Amazon cloud using GigaSpaces as the scale-out application server while:

* Not having to re-write your application
* Preventing lock-in to specific cloud provider
* Enabling seamless portability between your local environment to cloud environment
o No code or configuration change is required between the two environments
o Develop local - test on the cloud
o Built for iterative development