Introduction
My friend Will Hawkins, a man who I met just a few days after touching down in Houston weeks ago, encouraged me to write of some of my experiences regarding the deployment of technical infrastructure in a disaster zone. I'm going to give it a shot.
But first, the disclaimers: I am not a network engineer. While I once did make a short, terrible living by being a systems monkey for a small, putty-and-tape ISP, my understanding of the nitty-gritty of packets and their routing is mostly at an enthusiast level. Like baseball, I enjoy watching its execution by pros and can personally, during the hang of an exceptional pop fly, be graced with a reprieve to look up on Google the mechanics and syntax of moving from home plate to first base, but it's not the sort of thing at which I expect to make a living. I am much better at football.
Also, I am toying with the idea of putting together a 'tech truck,' a vehicle with which to quickly deploy to areas affected by communications-disrupting disasters. This needs to be disclaimed as I do hope to approach corporations and third-parties for donations, and intend to use this document as a piece of that appeal. Just so you know.
Many of the workers with CU Wireless, Radio Response, and Resource Action Group were deployed in much more devastated areas, and while I certainly learned from their experiences as well as my own, I do not mean to speak for them.
Logistical Recap
I arrived in Houston about a week-and-a-half after the levees broke in New Orleans. I entered the Algiers region of New Orleans nearly two weeks after the levees broke on the East Bank of the city. My experiences were limited to areas that, while lacking in supplies and utilities, were also predominantly physically intact. I was in the New Orleans area for about a month.
Intention of This Document
Besides those stated in the Introduction, it is my hope to catalog lessons learned about deploying communications infrastructure in a disaster area. This will be useful both to myself as an aid to future planning, and hopefully to others, to be digested before entering into similar relief scenarios. Yes, this is sounding way too official already.
What this document doesn't address is useful equipment lists. I have some ideas regarding that, but will chew on those a bit longer.
The Rest of This Document
It was my hope to travel into Katrina-affected areas and to write stories as a journalist, as well as provide assistance as I could in a mostly generic, 'geeky' way. I had been in communication with some of the people who eventually ended up forming Radio Response. Instead of heading to Rayville, LA, (the initial staging area), my traveling partner and I headed into Algiers at the request of community organizers Malik Rahim and Scott Crow. Our work there ended up laying a technical infrastructure for the grassroots community group
Common Ground.
While that decision precluded us from participating in some of the large-scale deployments being done in other areas—think multi-mile Wi-Fi hops to provide backhaul internet links to areas that were otherwise off the grid—it did offer an opportunity to work in a more hands-on fashion, as we not only provided technical support (in both the traditional and broader senses) to a community, but also allowed us to do thing like hand out food, water, and ice to those in need.
The Real Rest of This Document, With Bullets
These are some of the overarching lessons I feel that I learned in my work post-Katrina, as they apply to those considering deploying to disaster zones to provide 'geek aid.'
• DEFINE YOUR INTENTION - I put this first because it should be predominate in your planning, both at the beginning and throughout your effort. Your intention is to put people in communication with the outside world. 'To help' is noble thinking, but narrow it down. How are you going to help, and, once defined, how are you going to continually accomplish that goal?
• FORM A GROUP- Networking is an inherently social thing, but many tech folk seem to have a distrust of bureaucracy and structure. That's natural and understandable, but in a situation as disorganized as a disaster, having a group of people you can rely on—even if it's just to bounce around an idea or to request assistance—is invaluable.
Don't feel as though it has to be highly organized or structured for a long-term response, at least at first. Speed of deployment is critical, and your instinct to 'get out and start working' is spot on, but don't go it alone. Even a wiki, email list, or bulletin board goes a long way establishing an ad-hoc infrastructure.
Also, having a public face makes it easier for the geeks in the audience to offer their help. We had much support from members of the very communities we were assisting, simply because they read about our efforts on the web.
• INTERNAL COMMUNICATION AND DOCUMENTATION - Once you have made the first steps to establish a support network, maintain internal communication. Simple, daily updates as to your status help others to maintain situational awareness. Basic steps, like publishing your contact information, and recording the phone numbers and email of every single person with whom you interact into your computer and phone, will pay dividends at unexpected times.
As you begin to deploy equipment, much of which may be donated or purchased by others, even simple email logs can help others to keep track of resources. Recording password and default IP information is critical. And while security is important, be sure that others who may be working with the equipment have access to that information later. Default passwords and network topologies are your friend.
• LEARN ABOUT OFFICIAL RESPONSE - One of the great strengths I saw of smaller groups was their ability to fill the gaps left by official response groups like FEMA and the Red Cross (and at times, to act as a full-on replacement for those services when they fail). It is important, however, to be in communication with official groups so that your response will not be misapplied or seen as a threat to a long-term response from the government or its contractors. Most officials, in a disaster scenario, are willing to work to integrate your efforts. While ad-hoc groups are sometimes forced to act due to a lack of official response, making an effort to work within the system will, at worst, make your intentions public and known, and at best help you to avoid redundancy in the response.
• NEW EQUIPMENT - While equipment donations of all sort can be useful in the long term, press for new equipment when possible. I have personally witnessed truckloads of old desktop PCs delivered at great cost to disaster areas, only to find that the majority are not functioning. When every hour matters, it's preferable to have known-good hardware with which to work. Obviously, you take what you can get, but if you have the ability, purchase and request new equipment.
It is also optimal—and yes, disaster response does not deal in optimals, as a rule—to acquire large batches of standard equipment. If you can get a few dozen of the same make and model of a router, it makes in-the-field learning today old-hat tomorrow.
A corollary: You're building a network, just like you do in your day job. If it is a best practice in the 'real world,' then it's probably a pretty good idea in an emergency. Hopefully, the work you will be doing will be online for years to come. Pretend you are taking over the network from yourself. Are you happy with the level of documentation and the quality of work?
• LICENSES - We met a very unique problem post-Katrina, when we discovered that the web forms on the FEMA site only worked with Internet Explorer. While a good network administrator wouldn't allow anything on her network that might compromise its uptime later, sometimes you have to go back to rule one: What do you have to do to accomplish your goal?
This also touches on the usefulness of new equipment: new-in-box laptops almost always come with proper licensing. If using hand-built equipment, do your network and its customers a favor and document where machines are deployed that violate licensing so that they may be replaced with open-source or properly-licensed units when the immediate crisis wanes.
• PUT ASIDE IDEOLOGY - Related to licensing, but worth making its own point as it applies to more than just what operating system or applications you might be using. I've always maintained that a good engineer uses the tool that works, even if it isn't ideologically optimal. Will you be deploying client-facing terminals? If so, there's a better-than-average chance that those computers should be running Windows, at least in the short term.
My rationale is this: Statistically, it will be easier for the average person to troubleshoot Windows on their own instead of calling you while you're up on a roof duct-taping an antenna mast in a rainstorm. That said, if you've got a Linux distro that is nigh-on bulletproof and you think it will help your prime intention—putting people in communication with others—then go for it. I'm fairly firm on this point, but not to the point of ideology.
The reason this merits its own bullet point, however, is that you'll also find yourself, in a disaster area, working side-by-side with many people who come from greatly divergent backgrounds. Smelly hippies and close-shorn anarchists will be working in the same areas that the military and official aid organizations. To steal a bit from the Good Book (since we're talking about putting aside ideology here), 'By their fruits ye shall know them.' If someone is helping out the people who need it, then it's probably best to put aside your personal prejudices and get the job done.
That's not to say you should always defer to the judgments of others—you are there for a single purpose, which is to help the people of the area—but I have found that a smile and a handshake go a lot farther than an philosophical debate while knee-deep in disaster.
• BE FLEXIBLE TO NEEDS - You've got your goal. You've got your plan. Now why does this guy want you to help him tarp his roof?
It's good to stay on target, and you should use your judgement in situations like that, but as a communications person it's easy to think of helping large swathes of people instead of individuals. Which is more useful: Getting a community center online with the internet or helping an embarrassed elderly woman find some adult diapers? There's no real answer, of course, but I can tell you which one makes more clear the real effect you're having on the lives of the people you're there to help.
That's not to discount the work that we geeks can do, but I can personally vouch that you will find yourself questioning the usefulness of your actions from time to time. That's probably a good sign that you should take a little time and talk to the people you are trying to help and see what you can do to help them
right then.
• TAKE BREAKS - Gosh, these are tying together a bit more than I'd planned, but that's okay.
You will see and experience things that it will take you weeks and months to digest. You will experience human suffering in a more immediate way that you might have conceived before. It will wear you down. That's normal, human, and should be expected.
You will need to take breaks. I can't tell you what those breaks should be. In New Orleans, we had a curfew for the first few weeks, which was a forced time to at least stop running around each night. If I had to make a judgement, I would suggest a break of at least one day a week where you get away from the situation, either by leaving the area or reading a book or playing a videogame for a few hours. Alcohol will help in the short term, but won't provide you any productive, long-term release (although it can be useful to knock yourself out of 'emergency mode').
This is another more nebulous bit of advice, but just watch yourself. It's okay to note in your daily updates to your group your mental state. That will help to remind you to think about yourself on a daily basis, as well as appraise them of your situation.
The Ending... Or Is It? (It Is, Actually.)
I'm sure that there will be more things that spring to mind later, but if I can leave you with one thing, it is this: Just go. You'll know when you're needed, and you'll be doing good work for the right reasons. It doesn't get much better than that.
