.comment-link {margin-left:.6em;}

两个g的加速度

2gag.com旗下强势新晋子品牌,主要进行耸人听闻标题、无事生非转贴和白茫茫一片真干净无链接的技术研究工作。

20.6.06

 

赠给永远的过去,交给永远的青春

Simmons' Laws of System Administration

The Definition:

System Administration is the combination of system support and user support.


The First Law of System Administration:

Any rule can be modified by the application of power and policy. By contrast, rules always are subordinate to laws.


The Network Paradox:

System support is a subset of network support. Network support is a subset of system support.


The Laws Of Unanticipated Support Cost:

1. It will always cost more to support a thing than the vendor told you.

2. It will usually cost more to support a thing than to buy it.

3. Sometimes it costs 10x as much to support a thing as it did to buy it.

4. Refusing to support something often results in the thing being unusable.

5. Once it's installed, supporting a thing is sometimes cheaper than not supporting it.

6. Before buying, make sure you're committed to support. But see rule 1.



The Division Between System Support and User Support:

There's a difference between system support and user support. There may be overlap in the two positions; sometimes both are done by the same person. But the two tasks are distinct, and sometimes have conflicting goals.


The Law Of Distributed Talent:

Great system support people often make lousy user support people and vice versa.


The Paradox Of Dual Abilities:

The person good enough to do both system support and user support
will usually be hired away by a shop where the combined tasks are
too large for a single person.


On Complexity And Customization:

Application-to-application differences confuse everyone, especially users and support staff. Ditto UNIX-to-UNIX differences, etc. By contrast, complete consistency completely stifles improvement.

At any given site for any given application or feature, there's
someone who knows more about it than the support staff. Finding
that person is the first step to take to diagnose any given problem.

Time to diagnose and time to fix are fix are completely unrelated.
Sometimes one approaches zero while the other approaches infinity.
This is especially hard to deal with when the diagnostic person and the fix person are not the same.

One person's improved feature is another person's gratuitous change.

Users want applications and systems they can customize.

One user's customization is another user's gratuitous change.


The Laws Of The Cost Of Customization:

The cost of customization is complexity. The cost of complexity is increased difficulty in administration and user support. The cost of increased difficulty in administration and user support is either lower quality of administration and user support, increased support staff, or both. Therefore increased customization means increased cost or lower quality of support or both.


The Paradox Of Unused Customization:

It doesn't matter whether customization has actually been done. The mere fact that it's possible means you must check for it, thereby increasing the cost of problem diagnosis.


Smallwood's Law (Simmons' paraphrase):

They're not users, they're clients. -- Kevin Smallwood


Users Are Human:

The user who says "Can X be done?" is usually really asking "Would someone please do X?". Make sure you answer both questions.

It's human to blame problems on outside causes. By contrast, an
outsider will always suspect the insider as the cause.

The user who says "I didn't change anything" isn't always lying.
Sometimes they're just ignorant or forgetful.

It's more important for users to do their job than to answer the
needs of admins. Unless of course their job is to answer that need.


Admins Are Human:

For every statement in "Users Are Human", change "user" to "admin" and vice-versa.


The "You Broke It" Principle:

Cockpit error is the most common cause of problems. Everybody is
a pilot.


Support Is Overhead:

One way of cutting costs without cutting development staff is by
cutting overhead. System administration and user support are overhead.

User and system admin training are overhead. Not having them increases overhead. Go figure.


The Joy Of Being A Contract System Administrator:

"Sure, we can do that. Here's what it'll cost you."


His Site Isn't Your Site:

The situation at your site doesn't make you qualified to judge the situation at another site, and vice-versa.

Just because someone else's support staff does it mean your staff
can do it. (This statement is subtler than it looks.)


The Rules of Policy and Power:

1. System administration is whatever the boss tells the admins it is.

2. Users will bypass admins to get the boss to tell the admins something different. That's their right.

3. Most system admins live in a policy vacuum. This can be good or bad:

Corollary 1: Power expands to fill a vacuum. That thing which expands most easily is a gas.

Corollary 2: Anything that quickly expanded to fill a vacuum is easily displaced by a solid.

Corollary 3: A rapidly moving solid will hurt you if you're in its way.

4. The person who does your job review makes the rules. The good admins always follow those rules. See Rule 1 and the First Law.

The Summary:
Be careful what you do in that vacuum. Nobody appointed you god.
However, you can always be dis-appointed.


The Laws Of System And Network Growth:

You can always incrementally add one more.

Sometimes the straw breaks the camels back. More often, the
camel just goes slower and slower.

The difficulty of support does not grow linearly with the size of
the site.

Eventually your site outstrips your methods, and you must bite the bullet and move to new methods.

Corollary: Nobody bites the bullet until there's not enough time to do the existing work. At that point there's not enough time to make the changes.

Adding a new kind of computer, operating system, application,
peripheral, etc, has a much higher administrative cost than adding one more of what you've already got.

Corollary 1: If you buy one, you may as well buy ten.

Corollary 2: If you buy ten, you may as well buy eleven and keep one for spare parts.

g附:这真是目前为止最耸人听闻的标题啊。

9.6.06

 

四十三年 望中犹记 烽火扬州路




中文版编辑饭饭指出:
这本书由我的好朋友朱靖江翻译。他时常会在这个blog里留言。这是我第一次接触战争类的书,也是这么些年来第一次一口气读完一本书,第一次了解战争原来充满各种荒诞悲痛的细节,第一次没有因为在编书过程中过多阅读这本书而感到厌烦,第一次愿意把我的工作成果骄傲地公布出来,并且,这是我做的第一本和我的专业——历史——最相关的书。

相关背景:
《滇缅公路》一书,正是关于第二次世界大战期间这方曾被遗忘的丛林战场。矢志于为湮灭的历史拂去尘土,让更多的人记住曾发生于这片土地,由中、缅、印、英、美等国人民共同付出鲜血与泪水的悲壮故事,2002年11月,受美国《国家地理》杂志的委托,资深撰稿人多诺万•韦伯斯特从印度加尔各答启程,穿越缅甸境内的热带丛林,再度踏上这条在二战期间具有重要战略地位的利多公路-滇缅公路(本书译者朱靖江亦应《国家地理》之邀,陪同韦伯斯特共同探访这条战时公路在中国境内的段落),通过沿途极为艰苦的实地考察,多方探访当年的老兵以及修路者,韦伯斯特获取了大量第一手材料,写就了这部非同凡响的史诗故事:《滇缅公路》。2003年下半年此书在美国出版,在曾赴中缅印战区作战的美国老兵当中引起了强烈反响,美国评论界称其为描写中缅印战场最为生动翔实的一部历史作品,“是一部品质卓越的总揽之作”“期待它将会成为下一部《兄弟连》的蓝本”。


中文版读者连岳指出:
这本书我看了一部分,还没看完,看到最有趣的一个细节是,作者列举修筑滇缅公路的牺牲之后(好像是平均一公里要死一个美国大兵),忽然来了这么一句话:滇缅公路修成之日,也就是它被放弃之时。非常黑色。我看改编成《兄弟连》的可能性不大,倒是挺适合伍迪艾伦的——就这个细节而言。

Archives

09/01/2005 - 10/01/2005   10/01/2005 - 11/01/2005   11/01/2005 - 12/01/2005   12/01/2005 - 01/01/2006   01/01/2006 - 02/01/2006   02/01/2006 - 03/01/2006   03/01/2006 - 04/01/2006   04/01/2006 - 05/01/2006   05/01/2006 - 06/01/2006   06/01/2006 - 07/01/2006   07/01/2006 - 08/01/2006   08/01/2006 - 09/01/2006   09/01/2006 - 10/01/2006   11/01/2006 - 12/01/2006   12/01/2006 - 01/01/2007   01/01/2007 - 02/01/2007   02/01/2007 - 03/01/2007   03/01/2007 - 04/01/2007   04/01/2007 - 05/01/2007   06/01/2007 - 07/01/2007   07/01/2007 - 08/01/2007   08/01/2007 - 09/01/2007   09/01/2007 - 10/01/2007   12/01/2007 - 01/01/2008   02/01/2008 - 03/01/2008   07/01/2008 - 08/01/2008   09/01/2009 - 10/01/2009  

This page is powered by Blogger. Isn't yours?