Did you know you can use Chrono Boost on the Warp Gates to speed up the recovery time? You can! This is mind-blowing.
I was watching Team Liquid #11 tournament, White Rav vs. TLO. The game was casted by HD Starcraft. The Protoss player went with a 3-gate. If you go to 5:45 on the following video, you'll see how the player uses Chrono Boost to speed up the Warp Gate enery replenished. This is going to be a very useful tactic!
http://www.youtube.com/watch?v=iSq-2Cbj6Sk
Enjoy.
Tuesday, February 8, 2011
Monday, February 7, 2011
How to name Infrastructure devices
Description
Asset management is important when running an IT infrastructure. All items must be cataloged, kept in inventory, but most important is the ability to mentally generate the device name on command. This is crucial when troubleshooting a problem with one of your systems.
This article describes how to generate a device name. The steps are simple: determine the purpose of the device. All falls into place after that. Let's say you manage the infrastructure for a development team. The team is working on something, PROJECT X! for a client, ABC Company. The work requires a web server, database server, a switch, and a firewall. The recommended names are based on attributes. In this scenario, the names will be based on client name, project or system name, and device type. The result is a system called ABCPRJX. The devices in the system would be ABCPRJXWEB, ABCPRJXDB, ABCPRJXSWT, ABCPRJXFW. This may seem robotic and just odd, but it's required for communicating to other members of your team and keeping track of tens or hundreds of devices.
If more devices of the same type are required then add a number that increments as the need grows. If another web server is needed the it will be ABCPRJXWEB02. I recommend starting with incremental number, at the very start, as a base attribute to the name.
Dont be too strict
Roles change! For example, a particular web server may be a development server and then a production server simply because it works. This is by the "don't touch it" rule. The sales stage (production, trial, development, beta, etc) may be added as a base attribute to the name. On the flip side, it is difficult to move the data around and frankly, not necessary. The same goes for the location of the device. Virtualization makes it possible to move a server from one location to another.
Keep it short and simple (KISS)
The attributes are to be kept short. No one likes to type a long y device name like ABCCOMPANYPROJECTXWEBSERVER01. The system may throw an exception if a limit is reached. On the other hand, abbreviating certain words may back-fire. Take PROJECT for example. Some may choose PRJ or PROJ. It's out of preference, but should be communicated to the entire team.
No Dashes or Extra Printable Characters
Additional characters may help to read the name if it gets long. In my experience, the consistency is not kept. For example, one administrator may set the dash after the client name, another name set it after the system name. It gets out of hand very quickly and will defeat the purpose of the naming convention: to mentally generate the device name quickly.
Retiring a device
This is simple. Respect the device for the wonderful things that it did during its lifetime. The number is not to be reused after the device has been retired. Sooner or later, a question will come "what server was part of that system?". If ABCPROJWEB01 is reused, then everyone will undoubtedly get confused.
How many digits should I use
In my examples, I use a 2-digit convention. This is dependent on the growth of your infrastructure. In my case, using 1-digit will not be enough and 3-digit will just look odd. If it looks odd then the name will not be generated easily.
Recommendations
Suggested Attributes
Asset management is important when running an IT infrastructure. All items must be cataloged, kept in inventory, but most important is the ability to mentally generate the device name on command. This is crucial when troubleshooting a problem with one of your systems.
This article describes how to generate a device name. The steps are simple: determine the purpose of the device. All falls into place after that. Let's say you manage the infrastructure for a development team. The team is working on something, PROJECT X! for a client, ABC Company. The work requires a web server, database server, a switch, and a firewall. The recommended names are based on attributes. In this scenario, the names will be based on client name, project or system name, and device type. The result is a system called ABCPRJX. The devices in the system would be ABCPRJXWEB, ABCPRJXDB, ABCPRJXSWT, ABCPRJXFW. This may seem robotic and just odd, but it's required for communicating to other members of your team and keeping track of tens or hundreds of devices.
If more devices of the same type are required then add a number that increments as the need grows. If another web server is needed the it will be ABCPRJXWEB02. I recommend starting with incremental number, at the very start, as a base attribute to the name.
Dont be too strict
Roles change! For example, a particular web server may be a development server and then a production server simply because it works. This is by the "don't touch it" rule. The sales stage (production, trial, development, beta, etc) may be added as a base attribute to the name. On the flip side, it is difficult to move the data around and frankly, not necessary. The same goes for the location of the device. Virtualization makes it possible to move a server from one location to another.
Keep it short and simple (KISS)
The attributes are to be kept short. No one likes to type a long y device name like ABCCOMPANYPROJECTXWEBSERVER01. The system may throw an exception if a limit is reached. On the other hand, abbreviating certain words may back-fire. Take PROJECT for example. Some may choose PRJ or PROJ. It's out of preference, but should be communicated to the entire team.
No Dashes or Extra Printable Characters
Additional characters may help to read the name if it gets long. In my experience, the consistency is not kept. For example, one administrator may set the dash after the client name, another name set it after the system name. It gets out of hand very quickly and will defeat the purpose of the naming convention: to mentally generate the device name quickly.
Retiring a device
This is simple. Respect the device for the wonderful things that it did during its lifetime. The number is not to be reused after the device has been retired. Sooner or later, a question will come "what server was part of that system?". If ABCPROJWEB01 is reused, then everyone will undoubtedly get confused.
How many digits should I use
In my examples, I use a 2-digit convention. This is dependent on the growth of your infrastructure. In my case, using 1-digit will not be enough and 3-digit will just look odd. If it looks odd then the name will not be generated easily.
Recommendations
- For startups, use a 2-digit, incremental convention by default. You may get a 2nd or an Nth device of the same type. Hey, it can happen!
- Do not use Location or Sales Stage unless you have a method of changing the device name quickly without additional pain and labor.
Suggested Attributes
- Client Name
- Project/Product Name
- System Name (same as Client Name + Project/Product Name)
- Device type: web, db, domain controller (dc), switch (swt), firewall (fw), router (rt), monitor (mon), security (sec), terminal (term), service (svc), server (svr)
- Sales Stage (must be able to logically move the data from one device to another): Prod, trial (tri), demonstration (demo), BETA, user acceptance test (uat), development (dev), laboratory (lab), disaster recover (dr)
Subscribe to:
Posts (Atom)