January 19, 2012
Someone on Reddit asked a great question…
Their company just purchased another corporation, and the submitter has been tasked with creating a “State of IT” report. When I originally read the question, I thought that his current company’s president wanted an overview of the new company. As it turns out, the president of his company is actually from his NEW company and wants an overview of the existing IT infrastructure!
That’s ok, I answered the question that I thought I read, because I find it interesting.
If your president or CEO tasked you with creating an executive-level report of a company that they had bought, or had considered buying, how would you do it? Here’s the advice that I came up with…
- Finances / Tax information
If you haven’t, yet, you need to perform an audit of the hardware and software assets of the acquired company. Report on the value of the hardware and software that’s usable. Indicate how many pounds or tonnes of hardware will need to be recycled through an approved firm, and what the estimated cost will be.
- Broad overview of their infrastructure
This should be a high level, 10,000ft view of their network highlighting what it does to help the business, not what it does from a technical standpoint. If it’s a manufacturing company, sentences should sound something like…
IT in $U company supports the business by enabling communication throughout the enterprise via (internal email/instant messaging/internal documentation sites/etc), and empowers clients to share data via (whatever). The IT department consists of $X number of personnel, $N being senior with at least $A years of experience, $M number being junior. Last year, they had $Y business-impacting failures, with a mean time to repair of $L minutes.
- Upcoming problems
This should be a list of the major systems that need repaired or replaced, plus any grievous issues with the number or constitution of employees (i.e. massively under or over stocked).
- Remediation of problems
Should consist of a report of everything you foresee needing to do to bring the company’s IT up to your level of operations, with particular emphasis on the monetary element (i.e. an aggregate cost of software licenses, a per-major-system breakdown of new hardware (a new storage infrastructure, or new server replacements if they’re still running on pentium 2s), or “we’re going to need to hire three new junior level admins” or whatever).
Make sure to provide a time frame of when you believe you’ll be ready to spend money (estimate it on a quarterly basis, such as “we’ll need a new storage infrastructure with a likely cost of $$$,000 in Q3 of 2012). It should go through the issues brought up at the previous, matching one to one.
Also, assuming you have MTTR numbers in that company that aren’t where you’d like them to be, now is the time to list the plans you have to implement improvements, such as “Begin transitioning $NewCompany to our QA department test processes in order to improve MTTR”, and so on.
- Time Line
Unless the president plans on operating the purchased company as a standalone entity, he’ll probably want to have their services integrated with yours (and if you value your sanity, so will you). Here’s where it gets hard, because you have to account for a LOT of variables, and estimate how long it will take you to make adjustments to both your and their infrastructure (both will probably end up changing, unless you just completely dwarf them). Increase the amount of time that you think it will take, because it almost certainly will take longer, but establish a time line with the major events between now (completely disparate infrastructures) and full integration, and assign quarterly dates to those events.
I’m sure there’s more, though. What advice would you give to someone in this situation?
Posted in System Administration 
1 Comment »
January 16, 2012
I’m happy to announce the January 2012 LOPSA Columbus meeting! This Thursday, January 19th, we’ll be at the offices of 2checkout.com again (thanks Warner!). The address is:
2checkout.com
4350 Equity Dr. Suite G, 43228
Here’s a link to the Google Map: http://goo.gl/rafcE
View Larger Map
The meeting topic will be “Beginner and Advanced Monitoring with Nagios”, and the presenter will be….me!
At the meeting, we’ll have socializing at 6:30 (with pizza and soda), and the presentation will begin at 7pm lasting until 8pm. We’ll probably go out for drinks again following the meeting.
Please take this time to register at EventBrite (registration is free, but it lets me know how much pizza and soda to get).
Let me know if you need have any questions or concerns. I’m looking forward to seeing everyone at the meeting!
Posted in General No Comments »
January 14, 2012
This Thursday, we’ll be holding the 2nd monthly LOPSA Columbus Chapter meeting, and I’ll be doing a presentation called “Beginner and Advanced Monitoring with Nagios”.
I want to spend the majority of my time talking about configuring and managing Nagios, but compiling it takes valuable time, so in the announcement, I sent everyone a link to this page, and basically said “if you want to follow along, do these steps before the meeting”. And here you are!
I’m providing these directions not because I think that Nagios should be installed from source in a production instance (it shouldn’t – you can’t manage versions with a source install), but because it’s easy, and it’s a known quantity. And the lessons that we learn here can be applied to the distro-provided package (or an in-house packaged solution, if you do that sort of thing (and you should)).
We’ll be using the Nagios “Open Source” version, which can be downloaded here. As of right now, the current version is 3.3.1, but it may be newer by the time you read this, so click the first link.
We’ll also need some plugins, which actually perform the checks. You can download those here, (current version is 1.4.15, but again, get the newest stable version).
Now that you’ve downloaded it, lets compile and install it. The following assumes you have the development tools installed on your machine.
tar zxvf nagios-3.3.1.tar.gz
cd nagios-3.3.1
# You need to have installed development tools for the rest
./configure
make all
sudo groupadd nagios
sudo useradd nagios -g nagios
sudo make fullinstall
This installs Nagios into /usr/local/nagios/ – distribution packaging installs the various parts God-Knows-Where.
Now we’ll need to do the same for the plugins:
tar zxvf nagios-plugins-1.4.15.tar.gz
cd nagios-plugins-1.4.15
./configure
make
sudo make install
This installs the plugins into /usr/local/nagios/libexec – We’ll be using those plugins to execute checks for ourselves when we get going.
At this point, you’re ready to begin configuring Nagios…which I’ll talk about at the meeting! And I’ll make sure to post slides. If I can, I’ll try to have the talk recorded, but I can’t really promise that.
Wish me luck!
Posted in General 6 Comments »
January 4, 2012
I’ve been reading the Visible Ops Handbook (which is great and you should go buy it right now if you don’t own it), and it’s made me think about a lot of things differently – particularly the role of config management as an enforcement tool, not just a tool of convenience.
Before now, I’ve always kind of considered config management as a way to get things done, but part of the Visible Ops methodology is building fences around fragile resources. One of the authors’ suggestions is to use configuration management in this role, which can kind of augment something like Tripwire.
The reason that I even heard of this book is because Ben Rockwood talked about it in his keynote address at LISA’11. If you have a spare 45 minutes, you should watch that talk. Ben talks about the DevOps movement, and gives a lot of information on the backstory of how we got to where we are, even going so far as to discuss the history of the agile or lean methodologies back into the 19th century. It’s really informative.
Posted in General 1 Comment »
January 3, 2012
I’m currently in the middle of a little bit of freelance work for my old company. Not long after I left, there was another round of funding that led to them getting significant amounts of money to purchase new hardware. Figures, right?
Anyway, they’ve got a lot of stuff going on, so my old boss asked me if I’d be able to set up a couple of servers to perform automated installations, to which I agreed. This means that I’m playing with kickstart and Cobbler again…but while I’m walking through this, I do have to wonder…why put much effort into setting the initial configuration?
I mentioned Cobbler on twitter not too long ago, and the responses varied from “I really need to use that” to “We barely even use that anymore”, which reflects the general spectrum of system administration across the board pretty well.
My thoughts are that if you’re going to be using “best practices”, then you’re going to have a configuration management solution in place, be it puppet, cfengine, chef, etc. Why duplicate all the work you’ve put into your configuration management solution by doing it again in a kickstart file? It doesn’t make much sense to me.
If a simplified lifecycle of a server looks like this:
Why would we insist on making it look like this?
Anyway, food for thought, I suppose. I didn’t manage to get the puppet infrastructure completed before I left, and the new administrator isn’t sure which solution he’s going with, and has asked me to leave off puppet from these images.
What are you currently doing in regards to automated system builds? Do you still lay out the full machine config in the kickstart file (or its equivalent), or do you throw down a bare bones generic install that then is enforced to policy via config management?
Posted in General 11 Comments »
December 29, 2011
I did some work with Red Gate a while back, and some of that content is now being released online. Hopefully you’ll find it useful and informative.
What we have is:
- Networking: The Crib Sheet
When I wrote these pieces, I intended them to be tied together, and I didn’t expect everyone to have the underlying knowledge necessary to administer a network. Such a big part of understanding why our networks are laid out and configured they way that they are is understanding how TCP/IP operates. I wrote this piece to try to introduce the information necessary to really grok the rest of the work.
- Physical Layout for the Reluctant
Wrangling the configuration on switches and routers is only half the battle. We small infrastructure admins often find ourselves doing a lot of the physical work, too, and I don’t ever see any documentation for it. Which sucks. So I wrote this to help.
- Logical Network Layout for Small Networks
The documentation that I DO see is almost always about either large infrastructures or small home networks. Never anything devoted to the size that I admin. So I wrote this piece about building and managing small and medium business networks.
As I said, I hope you enjoy them. If so, please vote on them at Simple Talk, and let me know if you have any corrections or additions.
Posted in Networking, System Administration 1 Comment »
Email me
content rss