Get the Equipment
|
|
|||
|
|
Can I have the attention of the class? For one second? Okay, let's conduct a quick Selecting an ISP review. In the 101 course, you outlined your Web needs. In 102, you put your RFP together. In 103, you evaluated the proposals and (ideally) selected an ISP. Now in 104, we're going to prepare for the Web site launch. While selecting an ISP can be a long, arduous process, preparing to launch your Web site can make that look like a walk in the proverbial park. Much planning must go into this process. So let's get to it.
You are most likely in one of two possible positions: Either you have a Web site and you are moving the servers to a different ISP (HUGE pain) or you are putting up a new site (MUCH easier). Either way, you need a good solid plan to have a good solid launch. For the purposes of this column, I'll assume that the latter is the case and you are launching a new Web site.
To formulate the plan of attack, it's easiest to take a 10,000-foot view of the process to identify the major parts of the project and then slowly descend to get more granularity. From 10,000 feet, the site launch looks like this:
- Get the equipment
- Set up the equipment
- Launch the site
Let's drop the altitude a bit and focus in on getting the equipment.
This sounds trivial, right? You just call a hardware vendor, order the stuff, and charge it on your credit card. That's actually a really bad idea, and not just because credit card debt is evil. You should make better use of your capital. You should lease your gear.
Leasing
Given that the opportunity cost of capital for most Web companies is fairly high, you will most likely want to lease any equipment you need. Of course, this assumes that you can get good terms. If your company is new or your finances are less than stellar or your company is called something like Inexperienced Fly By Night Charlatans, Ltd, you (or one of the officers of your company) will probably have to sign a personal guarantee for the leased equipment. While that is kind of disconcerting, it's necessary.
To assist your finance folks in the leasing process, get a full price quote for all of the gear you will need. Happily the work you did in the first two Foo' Bar courses will help as you should have a complete list of all the hardware, software and any other stuff you will need for your site. You will have to send this list along with all of your financial statements (preferably audited or at least reviewed by an accounting firm) to the leasing companies. Count on four to five weeks to get the leasing deal signed.
Some of the leasing companies we have worked with include:
FL Financial Services, Inc.Once the leasing terms come through, your vendor will ship you the gear. After you sign the acceptance receipt for it and send that to the leasing company, the leasing company will pay your vendor. Do not sign the acceptance until you are sure that you received everything you ordered and that it all works correctly.
100 Pine St. Suite 560
San Francisco, CA 94111
415-288-4072
Fax: 415-288-4080Information Leasing Corp.
1023 W. Eighth St.
Cincinnati, OH 45203
781-444-7707
Fax: 781-444-1455Ameritech Credit Corporation
2550 West Golf Rd.
Rolling Meadows, IL 60008
847-290-5033
Fax: 847-290-9090
Sourcing
In terms of vendors, we have had very good experience with Computer Discount Warehouse. Gillian Gress is our sales rep (x 7313) and she is excellent. Like Sidewalk.com, if you need computer gear, Gillian can help.
One thing that many folks overlook is a VeriSign certificate. If you are going to do any SSL on your site (and you probably will if you are doing any e-commerce), you're gonna need one. So order it from VeriSign early in the process.
Set up the equipment
Once you have all the gear, the fun really begins. You have to set it all up. On each server, you will need to load the operating system, lock it down (just say yes to security paranoia), and do a burn in test. You will need to configure your switches, load balancers, etc. and test them. Then you will need to load your software (Web server, database, middleware, etc), and test that. Did I mention that you need to test all of this stuff? Well, you do. Setup the LAN just as you will at your ISP and simulate lots of traffic to your site. To stress-test our site, we use WebHammer as well as InetLoad. They work pretty well.
Contrary to what you may have heard, homogeneity is a good thing, particularly within Web sites. Whenever possible, keep the configuration of your servers exactly the same. It will be much easier to debug them. You also should assemble a "How To Set Up a Server" document. We make literally hundreds of tweaks to our servers. Nobody in the Motley Fool's TechDome can remember every single tweak. So we have a document on our intranet that has step-by-step instructions for setting up Web servers. Our techs don't even have to think about it. They just follow the recipe to bake the perfect Foolish server. If we change anything on the live site, the changes are reflected in the server recipe. This does not sound like a huge, important thing. But trust me, it is.
If you plan on doing remote management (and you will probably have to), make sure you have a way to access your servers. For our NT machines, we use pcANYWHERE. It's not perfect, but it's pretty good. Obviously you need to install pcANYWHERE on your servers before you ship them out. Otherwise you will have to pay the ISP staff to install it. For our Unix servers, we just telnet. Make sure you have telnet enabled and you have an account setup with which you can log in and administer the server.
Once you have set up and tested all of your equipment, you'll need to pack it all up again and ship it to the ISP you'll be using. Two words of advice here:
Label everything: Your company name, the machine name and the IP address for each machine should be on the front and back of each server. It should be big and legible. While crayon will handle the "big" part, it's not the best tool for the "legible" part. So spring for the Brother labeler. There are few things more annoying than asking NOC personnel to bounce a box and have them bounce the wrong box. Our experience has been that database servers in particular do not like random power cycling. So label 'em to avoid these issues.
When assigning machine names and IP addresses to your servers, make sure there is method to your madness and plan for growth. Assign names to your gear that make sense: Switch01, Web01, Web02, SQL01, SQL02, etc. Also, reserve IP blocks for similar servers, e.g. network gear is xxx.xxx.xxx.101 to xxx.xxx.xxx.110; database servers are xxx.xxx.xxx.111 to xxx.xxx.xxx.120; Web servers are xxx.xxx.xxx.121 to xxx.xxx.xx.150; etc.
Sounds boring, right? That's because it is. But trust me, your life will be much easier if you do it this way. It will be much easier to not only talk about your site ("Hey, we've lost the pulse on Web Five. Need a crash cart - STAT!"), but also remember what the IP addresses for each server are (very handy for telnetting and pinging).
Don't skimp on shipping: Make sure the servers are packaged very securely. We shipped out one server strapped to a pallet. It showed up at our ISP quite mangled and without the pallet. It had apparently been dropped out of an airplane. Keep that in mind when you're packing the servers. Also send them via a reputable company. And make sure you get a tracking number and track the packages. Another server we shipped out sat on a loading dock for 10 days because it was big and heavy, and the delivery folks did not want to hassle with it. Can you say customer disservice? Spend the extra time and money to ensure safe delivery of your equipment.
If your ISP has any questions about or issues with your site, they'll want to talk to you about them. So be sure to send a full contact list of your technical staff to your ISP. It should have full names, titles, work phones, cell phones, beepers, home phones (if you want), and e-mail addresses. If you plan to have your techies on 24-hour call, make sure you have a single hot line that can be forwarded to whichever techie is on call. That way the contact number is always the same.
Conversely, you should have a full list of contact info for your ISP. There are few things worse than seeing a server down and being unable to contact someone who can bring it back up.
You should also send a full list of what you want the NOC to monitor. If you just want them to ping your servers every five minutes, say so. If you want them to monitor specific services on your server, indicate which ones. If you want them to check for text in any of your pages, that should be explicitly stated. Basically - be as specific as possible about how you want your ISP to monitor your servers. The more information you give them, the better they can do their job.
<HandyHints>
Just because a server responds to pings does not mean that it is serving content. And just because a service appears to be running does not mean it is. To get around this, we have included a comment tag at the bottom of some of our HTML pages. Our monitoring tools are set up to check for that tag. If the tag's not found, we know the server is not serving and needs some TLC.
Send some replacement parts with your servers. You should have replacement NICs, video cards, power supplies, etc. on site. The amount and extent of the spare equipment will be inversely proportional to your tolerance for downtime.
Don't forget to send a good, expandable KVM (keyboard, video, monitor) switch with your gear so that the NOC can easily check your boxes.
</HandyHints>
Once the equipment has arrived at the ISP, the personnel there will unpack it, rack it and assign IP addresses to it (did I mention that each piece of equipment should be labeled with its IP address?). You will then need to test it again to make sure that nothing was damaged in transit. Sounds redundant to the testing you did in your office, right? It is. But trust me on this-you've got to do it or you will set yourself up for some nasty surprises. Make sure you test every single feature of your site on every single server. The work you put in on the front end will pay off in spades on the back end. Much better to do the testing during business hours than at 4:00 AM on Sunday morning when the NOC calls you to tell you that one of your servers is down.
The final task is to make the necessary DNS changes to make your site live. If you have a new site, you can do this whenever. If you are moving your site, this is a pain and the timing will be pretty important.
Time and Staffing
The above gives you a general idea of what is involved in actually setting up a Web site. You need to be much more specific. Drop some altitude and break down each task to the most granular level you can stand. Once you have a list of all the sub-tasks, estimate the amount of time required for each and assign the tasks to specific individuals. The individuals may work for you or your ISP. Once you have all that information compiled, you can sum the times to figure out how long this all will take. Once you have the total time, multiply it by at least 1.4. Again, trust me - this stuff never goes as smoothly as you hope. If you are familiar with Microsoft Project or something similar, use it. Make the file viewable by all involved so you can all be on the same page. Once you have the final plan together, make sure that everyone involved reviews it and signs off on it. This will ideally eliminate the "I didn't know" excuses.
Once you start the process, make sure everyone updates the plan as they finish tasks. This will ensure that dependent tasks are completed in the correct order. The key here is to manage expectations. Create a plan with as much detail as you can. Then communicate the plan to all the folks involved. If everyone on your team understands the plan, knows what is expected of them, what they can expect from the other team members, you greatly increase your chances of having a successful launch.
Starting with the next column, Mad Scientist Keith Pelczarski, of Fool Labs fame, will take the Foo' Bar reigns for a couple of issues. Keith will wax poetic about good layout & design then ramble about information and architecture, among other things. Of course, that's assuming that he doesn't end up ranting about one of his latest "experiments." Until then --
Y'all be Fool.
Related Links
Tell us your thoughts on this article or the issues it raises.
Have something Foolish to add? Our very own Foolish writers, Dwight Gibbs and Keith Pelczarski, can be reached at fool@nww.com
The Motley Fool
The premier site for investment advice on the Internet, of course.
The Foo' Bar archive
All the Foo' Bar columns, in one convenient place.
