Anyway hard to say how I feel about VCP. I'm very pleased to pass, since the only versions of VI I come across are older implementations, my own ESXi 3.5u4 server at home (yes I know how sad is that) and workstation (which I've used to isolate my own personal "desktops" for many years - great way to keep the peace in a relationship when one of you is ultra tidy by nature and the other isn't - I could create my own virtual mess while my partners PC stayed squeaky clean). Anyway about 9 of us did it together at work, with a lab and overview built by one of our in-house consultatants on vmware infrastructure, who did the vSphere update exam on the first week. The good news is that the pass mark has been dropped - it was about 70% out of 75 questions, now its 60% out of a 85 question pool, there are 10 unmarked questions.
I found the scenario questions the hardest - the ones where they show you a running vm or output from reports and it asks you what you should do next? Like add another cpu, power off a vm in the cluster etc etc. Performance issues basically. These can be tough to troubleshoot, especially if there is a lot of clusters. On the other hand, when I got the VCP 310 I shredded the manuals in the hhope of not revisiting for a few years. No such luck. However, this turned out to be a blessing, as the class manuals don't cover the material in anywhere enough detail to get a decent mark, or pass at all. What you really need to do is what I did, and base your study on the core documentation PDF set for vSphere. I also gave my desktop PC (which has a large 80GB hard drive hardly used) a new life as an iSCSI device using OpenFiler and got a Dell Poweredge 2650 from Hilco auctions for a mere 132 euros. Ok the cpus couldn't cope with ESXi 4, but they could happily run the last version of 3.5i which gave me a lot of practice with mucking about with resource pools etc. Ok a lot of the vCentre stuff and clustering stuff was not available to me but there is a good lot of detail in the manual, and if you clearly understand resource pooling on a single host basis, there isn't a huge gap to understand how this is then used in a clustered context.
If RTFM were not such a good mantra I'd have them tattooed on every persons head. Seriously folks, you wouldn't believe that I've worked with a few Gombeens over the years who thought they were too smart to follow instructions or take advice. Out of our group, we have just one colleague whose failed so far, with a fail mark poor enough for one of our experts to really question how he managed to do so badly. (I could tell him straight off that the lack of committment, not taking things seriously enough, pig-headed arrogance and a poor base level of skills carefully concealed by years of putting on the air of somebody mature and solid will be shown up at even basic cert exams).
I think one of the big difficulties that I had for many years was that entry level IT posts are so badly paid that if you don't have a lab or training programmes, its really difficult to get solid backgrounds on anything your job doesn't require. In fact a lot of places just refuse outright to offer any training over and above what is absolutely necessary - often meaning that they end up both with high staff turnovers, and have to hire more senior positions externally because they cannot bridge the skillsets themselves (which means they often end up havign to pay more for senior staff). It also has produced a whole generation of what I call Gombeen IT staff: seemingly competent staff, who have learned to "play the system" and bullshit past the basic requirements which they are often missing - solid server management skills, infastructure training on products such as DBs, Exchange, Active Directory, networking is a particular skill gap in a lot of the Gombeen IT men. A lot of them snuck into IT without qualifications and although they might raise to an A+ or an old NT or 2000 MCP, these were usually achieved through memorising vast pools of braindump questions, with little real world knowledge.
The trouble with these guys is that they are not so stupid that they cannot engineer their way into higher up posts and evade detection, sometimes for years. I was really shocked, for example, at one colleague, who it took me nearly 6 months to see through his deceptive but persistent campaign of being the solid "techie." His biggest problem, mind you, was a persistent refusal to follow other peoples instructions and advice, which sometimes had catastrophic consequences, as he has a "creative" streak, waywardly clicking on buttons that do something different rather than following instructions. As for women - like a lot of these techs, there is a serious belief that women cannot do IT. They are just intellectually inferior according to these Troglodytes. Years ago I had another colleague who (and this is a common ploy with Gombeen IT men) picked out a fringe application that nobody else knew anything about, and start signing off his emails with SME (Subject Matter Expert) on this application. Thats a very common method of deceit - find something you think nobody else knows anything about and claim experise. Of course, this generally doesn't work when you've got somebody like me around - I can spot an IT Gombeen from 10 miles away. My previous background included real world application support and massice enterprise support - some stuff of which really paid off.
But for me the key was working step by step through certifications and qualifications. I started with a Network+. Then I did ITIL 2 foundation. And then I got a CCNA. I did an A+ across 2 weeks on my lunchbreaks, at a point where I realised that this exam by then was easy enough to do just by reading a basic Mike Meyers book (I'd been supporting IT for 5 years by then and felt it was worth the couple of hundred euros). The benefit actually, was learning a little regarding SCSI. With this and networking, the next step was management of an infrastructure. My next job was just that - overall overviews rather than detailed stuff, problem management, pulling reports, delivering enabling information. Change management experience helped enormously too.
By the time I got to "pure" server support and delivery, I'd sufficient experience to not only just know the hardware, but also to really understand the dynamic of large corporate enterprises. I've rarely worked in a company with less than 50,000 employees. Most of my customers down through the years have been equally massive. This is where you really learn to stop being narrow minded and stop trying to focus on finding niches. The biggest danger facing a lot of IT people is that they push themselves into these "false dawns" - getting tied up with applications that vanish as so many get tied up in the new "next great thing."
My advice is this:
- Get a good knowledge of hardware, operating systems, networking and storage. Don't concentrate on any one area without a reasonable knowledge of the other. A server admin is almost useful if he/she doesn't understand networking concepts and have some basis for storage administration. They won't be able to properly troubleshoot modern enterprise level applications without this knowledge.
- Give time to application support if you get a chance but don't jump in at the deep end where the application requires high levels of programming knowledge in particular. If you haven't got a degree in IT or 10 years real-world experience, most employers and your peers will probably recognise you for the charlatan you most probably are, unless you really are genuinely gifted and can script anything rapidly and elegantly.
- Get to understand the business, both that of your employer and your clients. If you don't understand that you'll have a hard time making sense of business requirements and design specifications.
- Don't pooh pooh your colleagues in other technology areas. You don't know it all. If you think you are smarter on another subject area ask yourself why you are not working on that team? (Unless you've been promoted upwards). But don't sneer especially at people doing a very different job, even if you think you understand them. Especially don't jeer at their designs or ignore their instructions or advice. You might find that they are right.
- Women in IT generally have to work and fight much harder to get on. As a result you will often find they are way superior to their male colleagues. Get over yourself on this, its a simple reality that women face massive stereotyping and discrimination in traditionally male roles and so have to outperform to get the same outcomes. Forgetting this may prove very costly when that girl who you thought was oh so dumb is now your manager. Especially don't even think of engineering retaliation against women who get promoted over you - they've probably earned it the hard way. If you can't see that, take the log out of your eyes and stop being such a pathetic bully.
- Never be dishonest about mistakes you made or things you didn't do. Most IT systems have a detailed audit trail and you'll be found out.
- Don't look down on global colleagues or stereotype them - same goes as women. You don't understand them and they have it harder than you. Get over your sense of superiority or it will bite your ass.
- Don't sneer at qualifications, especially diplomas and degrees. People work hard to get these and employers regard them as a mark of discipline. If you haven't done one, consider taking night courses towards it. Modular courses are often a good and flexible low cost method to get recogniseable qualifications. A failure to do this may be seen as an indication of laziness and lack of commitment.
- Be willing to share the workload. Recogonise others efforts, especially those over and above.
- If you've read this through and recognise a colleague, the only real way to deal with them is to ignore them. They are a menace but if you let them play their mind games you'll only end up distracted and angry. Get over it for now, let them hang themselves and eventually you'll get promoted into a position where you can get something done. Employers eventually wise up to people like that and create rounds of redundancies especially for them.
