For a recent presentation on using availability groups for disaster recovery, I needed a test environment that contained multiple separate subnets – something that approximates what you’d see in an enterprise that has multiple remote data centers. I found bits and pieces of the configuration on other sites, but nothing comprehensive. This post will walk through the process of creating such an arrangement.
Mike Donnelly (b|t) invited the SQL New Blogger Challenge participants to join in this month’s T-SQL Tuesday, and I’m happy to accept – I’ve been meaning to write for a T-SQL Tuesday for quite some time. The topic is “Teach Something New”, which also happens to work well with a challenge issued to me by Mike Fal (b|t) – to write something about PowerShell.
I’m very new to PowerShell. I’ve wanted to learn it for a long time, but I’ve never taken the time. This spring, I’m making a concerted effort to find ways to use it in my work so I can finally get over that learning curve.
One feature of PowerShell that fascinates me is the provider model. A provider abstracts a hierarchy down to something resembling a path in the file system. In fact, the file system itself is implemented as a hierarchy in PowerShell. PowerShell extends this model, though, by allowing other systems to expose their hierarchies as providers, also.
Would your coworkers know how to handle your job if you weren’t there?
This question was top-of-mind for me last week as I headed out-of-town for a family emergency. All too often, my answer to such a question has been “no” or “somewhat”. Many people in IT (consultants included) would have to answer that question the same way. But that’s the wrong answer.
We often prioritize documentation lower on our lists than “getting real work done”. We have plenty of
excuses reasons excuses: “it’s boring”, “it’s tedious”, “I don’t have the time”, “no one asked me to do it”. My favorite: “I don’t need to document my project – my code’s self-documenting.” (Yup, I used that one when I was younger.) Whether your code (or architecture, or whatever) is self-documenting is irrelevant. The point of the documentation is to give the reader a brief overview so they can quickly get to the task at hand, whether that be a modification or troubleshooting. Why ask your coworker (or yourself!) to waste time trying to figure out a system? You’ve already done that.
So how to fit it in? The easiest thing to do is document as you go:
- When you’re planning the system, make notes. Use those as part of your documentation.
- Make notes when you run into something particularly tricky or troublesome or unusual.
- Write out recovery instructions while you’re fixing that problem you discovered in testing.
- Building a test enviroment? Perfect. Jot down the steps you take as you do it as a model for your production build, and take screenshots for added flair.
- And speaking of screenshots: grab them liberally, especially when you make changes using the GUI. A picture really is worth a thousand words.
If you make notes as you go, writing the actual documentation is much easier. You don’t have to write a novel, and you don’t have to write like Shakespeare or Hemingway. Just put together your notes into something coherent. Even just collecting your notes is a step in the right direction – the fact that you did something is better than nothing.
One more common excuse: the backlog of documentation that is not done. If you wait until you have time to document your entire environment, you’ll never start. The time required would be prohibitive. Instead, start from where you are now. Create good documentation for the next project you work on. Maybe add a system diagram when you have to troubleshoot a system or train a new coworker. Add a rollout plan after the next release. And plan an hour or two sometime to document that old, reliable system that you never have to modify. By taking small steps, you’ll eventually have a sizable set of documentation that covers many common situations.
The bottom line is that creating documentation doesn’t have to be difficult or time-consuming. Just start. You never know when you might need it.
The response to the SQL New Blogger Challenge I issued a couple of weeks ago has been absolutely incredible. At last count, I’ve seen more than twenty (!) bloggers (besides myself) say they’re going to take the challenge, and I’m sure there are others I haven’t seen.
Thanks to David Klee, Paul Randal, Brent Ozar, Steve Jones, Andy Warren, Aaron Bertrand, Mike Fal, and everyone else that helped to spread the word, and thanks to all of the experienced bloggers that have been offering their encouragement.
If you’ve written a post for the Challenge, don’t forget to tweet about it with #SQLNewBlogger so we can all find it. And if you’re just finding out about the Challenge or couldn’t join us in week 1, no worries! You’re welcome to join in at any time.
I can’t wait to see what everyone has written!
TL;DR – In April, I’m challenging myself to write (and publish!) here regularly, and I’m extending an open challenge to other new bloggers to do the same. Interested? Read on.
I enjoy reading Seth Godin’s writing. Many of his daily posts speak about allowing your creativity to flourish and about building communities by simply allowing your voice to be heard. It’s all about the conversation, about making connections with other people in your own way. It’s all about allowing yourself to take the risk – not only the risk of failing, but also the risk of succeeding. To do that, he says, you have to create, you have to ship, and you have to do it regularly.
In January, he issued a challenge to his blog readers called the Your Turn Challenge, named after his most recent book. Those that accepted the challenge would commit to publishing one blog post per day for a week. The posts had to be public, and they were publicized via a Twitter hashtag. I thought this was a fantastic idea. Unfortunately, the week of the challenge was the week I was leaving on a long-planned family vacation to Walt Disney World, and blogging was not an option. So I did the next best thing: I promised myself that I would do the challenge myself in the near future.
That future is now. In April, I’m going to take the Your Turn Challenge. But what fun would it be to do it by myself? Therefore, I’m challenging other new bloggers in the SQL community to join me. The rules will be simple:
- Write – and publish – at least one post per week during the month of April.
- Weekly posts should be published by 11:59 PM each Tuesday (April 7, 14, 21, and 28).
- Posts must be published on some sort of public forum. This can be your own website, Tumblr, WordPress.com, Blogger, LinkedIn – anything, as long as it’s public.
- Write on any topic you want.
- Tweet your posts after they’re published using the hashtag #SQLNewBlogger.
The idea with the challenge is to have fun writing and to get ourselves comfortable with publishing what we write (often the hardest part!). I also hope that some who take the challenge will stick with it after April has passed, and we will end up with some new voices in the SQL community. After all, we can never have enough!
And what if you’re an experienced blogger? No problem – everyone’s welcome to join the challenge. Join in yourself (maybe to get back into the habit after a hiatus), or offer encouragement or ideas to those of us in the challenge. The more, the merrier!
Personally, I’m nervous about this. I’ve attempted to get my blog going for quite a while, and mental blocks have always stopped me. I’m putting a piece of myself out there for public criticism, and that’s a hard thing for me to do. However, there’s only one way to get comfortable with blogging, and that’s to do it.
I’m looking forward to the challenge. Will you join me?