Paging systems and Conference Bridges for startups & small teams

by Jesse Robbins | @jesserobbins | comments: 17

Early registration for the Velocity Web Performance & Operations Conference has opened. To help spread the word, I've written this "simplest thing that will work" hack to a common Operations need: Paging systems and Conference Bridges.

Step 1: Establish a team contact list with SMS email addresses

Create a Google Spreadsheet to create a team roster like this one. My recommendation is to let people enter and manage their own information. Most cell providers have an email to SMS gateway of some kind. In the US, these are:

• ATT: phonenumber@txt.att.net
• Nextel: phonenumber@messaging.nextel.com
• Sprint: phonenumber@messaging.sprintpcs.com
• T-Mobile: phonenumber@tmomail.net
• Verizon: phonenumber@vtext.com

Step 2: Set up a notification email list

Set up an email alias and add people by email address and SMS gateway address. If you don't have a way of creating an alias, you can use a mailing list provider such as Google Groups.

Step 3: Set up the Conference Bridges

I am really happy with FreeConferenceCall.com which, amazingly, provides free conference call bridges. I recommend setting up three different bridges, and naming them by color so you can refer to them as the "Red Line", "Blue line", etc.

Step 4: Test your notification & conference bridges

Test your notification system to make sure people get the pages and can dial in and use the conference bridges as expected. I've found that it's easier just to give everybody the "host code" instead of having some people using the "participant code". Your mileage may vary. Once you have verified that people are getting pages and can dial into the conference bridges you should...

(continue reading)

WebOps Hack #1: Simple Availability Report for Busy Teams

by Jesse Robbins | @jesserobbins | comments: 2

I created this spreadsheet for tracking availability and "days since last outage". Along with the availability and uptime calculations, it asks the following questions:

• What broke?
• Why?
• What fixed It?
• What did we learn?
• How can we prevent recurrence?
• Who owns follow-up?

I've found this to be the "simplest thing that could possibly work" for identifying problems and tracking issues before a formal incident tracking system is in place, or with vendors or other teams who you want to keep honest. Please let me know if it's helpful for you and how it might be improved. (Feel free to improve upon it yourself too -- it's Creative Commons Attribution Share Alike.)

Link to the Google doc is here. You need to "Copy to a new spreadsheet" to be able to use it.

Technorati Tags: infrastructure, operations, secretsauce, startups