In this lesson, I'll talk about planning for disaster. And this is little different than disaster planning. We don't plan for disasters, we plan in case disasters happen. So building disaster planning, or planning for disaster into all of our systems, is the ultimate goal. So I'll discuss about different types of disasters, how we can prepare for them and also differentiate a little bit about disaster planning. Disasters are inevitable. During the Fukushima nuclear disaster in 2011, we saw fallout for information technology all over the world. It wasn't necessarily caused by the nuclear disaster, what it was caused by, and the reason I say the Fukushima nuclear disaster is because that's what everyone remembers. What really the disaster was, was the tsunami that happened. And what happened was, there is flooding caused by that tsunami in Thailand. So 40% of the world's hard drives are manufactured in Thailand. So what happened during that disaster? Well, the price of hard drives skyrocketed. There was shortages of hard drives in the world because we couldn't manufacturer the hard drives. So it just goes into a little bit about, while we may be safe in one particular area, we don't think about, "Okay, a tsunami is going to cause hard drives not to be delivered when I need them." We don't think about that kind of stuff. So understanding what could go wrong in planning for it, is again, our ultimate goal. So natural disasters. The most common natural disasters the way I see it in order of could be a disaster is, earthquakes, flooding, storms which that means lightning, tornadoes, power outages, wind, fires and tsunamis. So cyber attacks and insecurity also are a disaster for IT. They could very well be a disaster. So we have to include things like hackers, and hacktivists, and incidental exposure, misconfigurations. Several weeks ago, Amazon actually had a misconfiguration in one of their server farms which caused a 15 minute outage for many of the companies that use Amazon to host their servers. Well, that 15 minute outage, cost around $150 million. So let's look at how we plan for disasters. Well, several years ago here in Colorado Springs area, we actually had a fire, wildfire and it was called the Waldo Canyon fire. So we watched me and several other of the IT guys ran up to the third floor of the library and saw the fire crest over the mountain. So we're not too far away from the mountains and we were contemplating at that time, while we have active data centers, we don't have another strategy for offsite backup. I mean, we have somewhat of a strategy for offsite backup for certain things, but not to the extent of everything. So we were contemplating, "If the fire gets closer, how in the world are we going to take our SAN that stores all the massive amount of student data, wheel it out of our data center and put it into a truck and get it out of here before a fire would take out the university?" Luckily, it didn't come to that but many homes were destroyed. And it could have been detrimental to our business which is teaching students. Student data, student grades, all would have been destroyed. That is something that we don't think about, we're in the middle of a city. So thinking about disaster and what could happen, gives us an advantage of planning for it in the future. Regular exercises also allow us to plan for that kind of disaster. A tabletop exercise is a great way to make sure that whatever we are doing for disaster planning actually works. We sit in a room, somebody comes up with a scenario that's maybe a third party, we've engaged our emergency management here at the university and they came up with a scenario and guess what? We realized a lot of stuff wasn't planned for. How do we transfer phones? How do we provide Internet if the entire campus is taken out and we have to go to, well, not the entire campus, but several buildings on campus where our data centers are? How do we diversify just a little bit more? So what have we done? Now we have generators in place, now we have dual routing centers, now we keep offsite backups. Planning for this helps. Diversity is key to IT, just like it is in investments. If you hear that you should store money in a bank, and you should store money in the stock market, you're diversifying your assets. Same thing in IT. We need to have different assets in different places to ensure that the business stays up. Ready.gov, which is the US site emergency management web site will tell you a lot of areas that you can make your IT departments run more efficiently with disaster planning in mind. Tests with outside groups, tests with your emergency managers, engage your local government to help you out. There are plenty of resources out there to test this stuff. Here in Colorado, the real natural disaster that we have to worry about is not earthquakes, it's not flooding, it's really not fires where we are, it's lightning and wind. So in the past several years, we get brownouts all the time. So having something that is protecting our infrastructure from electricity, is key to make sure our systems are running smoothly and we don't have any dead equipment if a lightning were to hit the building. Test your plans thoroughly. Once you've developed a disaster recovery plan, then we can test it thoroughly and make sure that it works. Test it regularly because if you don't test it, how do you know it works? So in conclusion, planning for disaster is not a bad thing. Disaster Planning is a little different. Again, that we're planning to have something go wrong instead of planning for the disaster, we should be planning for any type of scenario that happens. So extra hard drives, dual routing centers, dual Internet connections. So think about those when you're developing systems. They should always be thought about. Disasters should always be thought about while we're developing systems and putting in services.
