IT Job Descriptions and Salary Data Latest News

• Perform an initial risk assessment to determine current information systems vulnerabilities.
• Perform an initial business impact analysis to document and understand the interdependencies among business processes and determine how the business would be affected by an information systems outage.
• Take an inventory of information systems assets such as computer hardware, software, applications, and data.
• Identify single points of failure within the information systems infrastructure.
• Identify critical applications, systems, and data.
• Prioritize key business functions.

• Work Plan - The first step is to select the group of people who will form your disaster recovery / contingency planning committee. Include high-level managers, consider representatives from all the departments within your business, and, if possible, include a human resources representative as well.
• Current contact list with multiple methods of contact - Not only should you keep a list of the names of all employees, but that contact list should include alternate ways that people can communicate with each other. Include home phone numbers, pager numbers, non-work e-mail addresses, and cell phone numbers.  Create a formal phone tree that can be activated should you need to get in touch with your employees quickly.
• Organizational Succession Plan - What if several members of your management team were in an accident and couldn' t perform their regular responsibilities? What if key members of your company simply couldn' t be contacted for a period of time when you need to make some critical decisions? To prepare for this kind of circumstance, you need to consider a clear chain of command and authority. If key personnel are missing, who' s in charge? Who makes decisions?
• DRP/BCP Organizational Chart - Have a single decision-maker. That person needs to know the steps to take in a crisis, and how to reach all employees and other essential contacts (clients, customers, etc). And employees need to know who to take direction from in the chaos that frequently follows a disaster.
• Physical work space alternatives - If something happened to your offices, what would you do? Can employees work out of their homes? Is there another company that would share their facilities with you temporarily until you can rent or buy space at a new location?
• Risks and vulnerabilities - Make a checklist. Do you live in tornado alley? Put tornado damage on that list. Do you work in an office with no alarm system? Put building security on the list. Might layoffs occur sometime in the future? Add workplace violence. What if the phones get disconnected? What if your key supplier can' t get shipments to you?
• Backup your data - Most people have thought about backing up their computer data. Where are your important papers and files - both print and electronic? If your office computers or servers are destroyed, you' d better have your data recently backed up off site.

• Bulk copy with CIFS, NFS and FTP - For many scenarios, backup and recovery is no more complicated than scripted file copies. However, these protocols are notorious under-performers when it comes to WANs – even on Quality of Service (QoS) guaranteed MPLS links. If they are even copied at all; the combination of byte caching and object caching means that only the changed parts of files need cross the wire. For most bulk transfers a 10x increase in performance is common.
• Differential Backup applications - These applications keep track of file changes and only pass changes between locations. However, they, too, can be dramatically compressed using byte caching technology and are subject to the same bandwidth contention issues of any other application if a traffic control solution like MACH5 is not in place. Although some use proprietary protocols for transmission, those that use the underlying operating system benefit from protocol optimization. For most backup applications, a 3x performance increase is common.
• Database Replication using native SQL replication - Oracle replication and Microsoft DTS use complex SQL statements to automate data transfer. Byte caching and compression removes the inherent redundancy of this data, while user-aware bandwidth management can separate database use from database backup and allocate bandwidth accordingly. For most SQL automated transfers, a 3x performance increase is common.
• Database Replication using log shipping - Once the database files are dropped to flat files, they are usually transported as part of a bulk copy. These files are highly redundant, and byte caching and compression can improve their transfer dramatically. Further enhancements from optimizing the underlying transport protocols help as well. For log shipping, a 10x performance increase is common.
• Data Replication using web services as part of a Service Oriented Architecture - As SOA gains popularity, transporting data from different parts of the organization as XML over HTTP and HTTPS will become more common. Use internal and external SSL encrypted Web services.

exposure to the threat? How does the company minimize the impact disaster event to the business? For example, our small distribution company could employ an emergency power supply to mitigate its power outage threat and have all its data backed (see Backup and Backup Retention Policy - http://www.e-janco.com/backuppolicy.html), which are stored at a remote site when the hurricane occurs. The more preventative measures you establish upfront the better. Janco Associates say, "Money spent in preparation and testing are worth more than dollars spent in recovery."

The results of risk assessment should be a comprehensive list of possible threats, each with its corresponding solution and cost. The disaster and business continuity planner must present all of these threats to the business operations management, so they can make informed decisions regarding the disaster recovery budget.  The disaster and business continuity planner needs to communicate the risks the business faces from disasters. Business operations can fail to budget funds but they must do so knowing what risk they face and accept in doing so.

A good place to begin is by presenting the cost of downtime to the business. How long can your business afford to be without its computer systems should one of your threats occur?

Ultimately, the business operations unit decides which threats the business can tolerate. When developing a DRP (see Disaster Recovery Plan Template Business Continuity - http://www.e-janco.com/DisasterPlanning.htm), disaster and business continuity planners are shooting in the dark without those business indications. Both the disaster and business continuity planner and the business units must agree on which data and applications are most critical to the business and need to be recovered most quickly in a disaster. The management of our small distribution company, for example, may decide they can budget only for the emergency generators and the company will have to assume the risk of an minor hurricane.

It should include:

• Adequate communication coverage of the affected area.
• Mobile communication devices and terminals for disaster recovery personnel with voice and data capabilities.
• Group voice communications among on-site personnel with push-to-talk support for voice.
• Voice and data communications between disaster recovery personel at a remote location as well as with a 'disaster-management command center'.
• Internet service to provide information exchange with the outside world.
• A satellite uplink for the network's entire external traffic.

Once the data arrives at the central location, the backup and restore policies employed must include an offsite protection strategy for that location. Whether employing direct disk-to tape, disk-to-disk-to-tape, or other methodology, the organization's data cannot be considered truly protected until it is secured at an offsite location.

As a first step in responding to an irregular condition, the selected technology should attempt to notify both the people who depend upon the continuance of computing services for the performance of their duties, and those people who may be expected to be capable of dealing with the detected problem. It should maintain a history log, for future reference, of sensed conditions and actions taken. The roster of people to notify should include:

• System Users
• Site Managers
• Security Personnel
• Maintenance Personnel
• Service Bureaus and Alarm Co. Central Offices
• Authorities at Remote Sites

Given the human tendency to look on the bright side, many business executives are prone to ignoring "disaster recovery" because disaster seems an unlikely event. However Janco has found that over one third of all enterprises have had to activate their Disaster Plans in the last few years.

Business Continuity Planning (BCP) suggests a more comprehensive approach to making sure you can keep the enterprise going and meet it business objectives. This goes beyond the enterprise computers, networks and data bases.  However, the two terms are married under the acronym DR/BC or DRP/BCP. At any rate, Disaster Recovery Planning and/or Business Continuity Planning facilitate how a company will keep functioning after a disruptive event until its normal facilities are restored. 

(Reuters) - Delta Air Lines Inc will soon start rolling out broadband Wi-Fi access for its entire domestic mainline fleet of more than 330 planes, the U.S. carrier said on Tuesday.

The access will cost $9.95 on flights of three hours or less and $12.95 on flights of more than three hours.

"Beginning this fall, our passengers will have the ability to stay connected when they travel with us throughout the continental United States," said Richard Anderson, Delta's chief executive officer.

Delta expects Wi-Fi to be available on all its domestic mainline planes by the summer of 2009.

In todays network environment, as many as 60 percent of backups simply do not complete successfully. That means a lot of time and resources are expended while troubleshooting backup problems. And many organizations never test their backup data or recovery procedures. Can data be recovered? How long will it take? Will the recovered data be usable? Often, nobody seems to know. Even when backup technology works as intended, it often does not scale well or adapt to change in business requirements and network infrastructure. Nor does it deliver the timely, meaningful reporting that is necessary to develop efficient data-growth and related recovery strategies.

A backup-centric protection model just is not nimble or flexible enough to deal with the growing complexity of doing business in an always-on, digital world. By contrast, a recovery-centric protection model takes a broader, more holistic view of protection that is independent of specific functional technologies. It is a different way of thinking about protection that delivers measurable benefits.

Flowing directly out of contingency policies, the contingency plan details the roles and responsibilities of departments and individuals in keeping technology systems available, as well as the procedures for restoring IT systems during an emergency. Other key elements of contingency planning include resource requirements, training needs, the frequency of training exercises and testing, maintenance schedules, and data-backup schedules.

The phases of a contingency plan include the initial notification and activation when the emergency strikes, restoration and recovery once emergency teams have been mobilized, and finally a return to normal operation - or available to help organizations develop and maintain accurate inventories of IT resources. Vendors offer modules that use software agents to scour the IT infrastructure, storing details about hardware and software assets and their configuration parameters in configuration management databases.

• Ensure that your recovery plan is not attached to any one person.
• Keep your plan portable, and keep it away from you
• Make arrangements in advance with software vendors for license keys to put backup software at the disaster recovery site in operation.
• Contact phone lists should also include vendors.
• Remember the little things, like mice -- companies that develop disaster recovery sites may have all the servers they need, but they sometimes overlook essential hardware peripherals.

Consider this, almost 40% of small businesses that close due to a disaster event never re-open. What would you do if the building your business is located within was damaged or destroyed in a disaster? Where would you go to continue providing your customers with your business services? Would you be prepared and have the correct resources, databases, contact information and other necessary items to adapt to these changes? Having a disaster plan that identifies these important items will help ensure your business is prepared to survive during unexpected and difficult times!

As historic floodwaters start to recede along the Mississippi and other Midwestern rivers, local businesses in affected communities like Cedar Falls, Iowa, are busy assessing the impact on IT equipment and whether disaster recovery plans stood the test.

A maker of computer games in Cedar Falls, may be permanently displaced after Cedar River floodwaters reached 6 feet in its administrative offices and 5.5 feet in an adjoining warehouse. The company sustained about $250,000 in damage to inventory.

The firm's president said all 65 employees are now working temporarily in borrowed offices in three facilities.

As the floodwaters approached on June 9, employees scurried to save 120 PCs, 80 monitors and eight servers. Three high-end printers could not be removed in time.

The company plans to revise his disaster recovery plan. "When a river comes up 6 feet higher than it ever has before, it's tough to have that foresight," they said. "But it is probably going to happen again."

A software development company has plans to deal with tornados and electrical outages, but executives never dreamed they would have to contend with the Cedar River surpassing 500-year-flood levels. "Going through this experience [will] make those plans [more] than just part of an IT checklist," he said.

A key lesson learned was that companies must prepare for employees to miss work to help families and communities after natural disasters.

(Computerword) - The Planet.com Internet Services Inc. hopes to have all 9,000 of its servers in its Houston data center back online later tonight following a blast that shut down the facility on Saturday afternoon.

When firefighters arrived at around 5 p.m., they could see "light smoke" at the Planet data center -- the aftermath of an explosion in a network gear room that produced enough force to move walls. Sprinklers quickly doused whatever flames erupted; the fire was attributed to an electrical problem with a transformer, according to a Houston Fire Department spokeswoman. There were no injuries.

Although the data center says it has power systems that "are designed to run uninterrupted" and a "fully redundant network operations center" with diesel generators, the electrical problem exposed an apparent Achilles' heel in its business continuity planning. Firefighters told data center workers to turn off all the power, according Planet spokeswoman Yvonne Donaldson. That meant the servers, even though they weren't damaged, were offline.

Approximately 6,000 of the affected servers were returned to service early this morning. Another 3,000 were due to return online by tonight, the company said. The Planet staff provided updates on the restoration on its customer forum site, including a message from CEO and Chairman Douglas Erwin, who wrote that some servers will be relying on generator power for a week until normal utility connections are restored.

The Planet operates more than 40,000 servers at multiple data centers and hosts more than 3 million Web sites.

While Planet data center staff worked to restore service, users -- many of them small business owners -- wrote of their frustrations over the outage on forum posts. Questions about the data center's backup capabilities were raised, as well. One person, flynnibus, wrote: "You shouldn't put all your money into one bank -- and you shouldn't put all your servers in one DC [data center] if you want to be truly resilient."

The NOTAM (notice to airmen) system provides notices to airmen, or pilots, regarding airports, equipment and security issues. The system went down late May 22 and was back up at around 7 p.m. on May 23.

Because of the disk failure, information had to be delivered to pilots through local air traffic controllers and alternate systems, including a Web site set up to disseminate the most up-to-date information, said a manager of aeronautical information management for the FAA. However, flight safety was never a problem, the FAA said.

"What happened was the drive in an end-of-life Sun box failed in the middle of updating the information on the hard drive, so it screwed up the database," the FAA said.

That was the beginning of the complications. The FAA team replaced the hardware and the drive which got the system running again.

The FAA already had the equipment to replace in place, they just had not done it yet, and that is why the hardware recovery was quite simple according to the FAA.

But even then, the system was running slowly, or in a deteriorated mode, and it got so bad that his team decided to reopen the problem to see what was going on.

As the technicians were working to fix the database, they decided to go to the backup system. As they did that, they soon realized they had written the error over to the backup system and had corrupted that system as well.

But what good does it do for IT to restore applications and data if there is no one there to run things? It is only half the solution, albeit the first half. The second half is the contact information for the business continuity piece. Recovering from disaster is less a solution than a process. Governments must take control of their own destinies. In the event of a disaster, a core team of people across all departments is typically designated to continue business operations pending the restoration of a normal work environment. These people need accurate information with which to call on IT and on vendors for technical support or to report to work at a temporary site.

A common area of confusion in dealing with replication is the distinction between consistency and synchronicity. Many newcomers to replication tend to focus on synchronization issues when, from a recovery perspective, consistency may be the true requirement from an application perspective.

So what is the difference and why is it important? Synchronization implies complete and continuous fidelity between local and replicated data stores. With true synchronous replication, a write operation is not acknowledged until it has been written to the local storage system and replicated to the remote storage system. This certainly provides a very high degree of consistency, but it also carries with it high costs and significant limitations regarding distance and latency that can impact application performance.

Synchronous replication is found primarily in the domain of the top tier of enterprise storage offerings and is usually reserved for those applications that are characterized by very high transaction rates where the recovery and re-execution of lost transactions would be difficult and costly.

The majority of replication is therefore of the asynchronous variety -- meaning that there is some degree of variance, based on change rate and available bandwidth, between the local and the replicated targets. In other words, by definition, the source and target are inconsistent with one another.

However, consistency still plays a critical role in the recoverability of asynchronously replicated data. The key is in understanding the interdependencies among related data components of a particular business function and ensuring that they are consistent among themselves at any given point in time at the target location. They may lag behind the original, but as long as they are equally behind, the function or application should be recoverable.

Although the notion of consistency groups is well established among enterprise-class storage systems, it may be less so for other forms of replication. Understanding consistency requirements and the ability of replication technologies to meet them should be a high priority consideration in disaster recovery design.

Add to that the processes necessary to support a Business Continuity and Disaster Recovery Plan and enterprises have an ever increasing complex problem.

Data recovery specialists at Kroll Ontrack Inc. painstakingly retrieved 99% of the information stored on the charred 400MB Seagate hard drive's 2.5-in. platters over a two day period after the device was discovered six months after the 2003 shuttle crash. The device was found in a dried up lake bed along the shuttle's debris area.

The successful retrieval of the data was disclosed in the April, 2008, issue of the Physical Review E journal, which published data from tests performed by the shuttle astronauts on the critical viscosity of xenon gas, according to published reports. The results of the tests were stored on the disk and retrieved by Kroll.

The Columbia disintegrated upon re-entry into the atmosphere of Earth on Feb. 1, 2003, killing all seven crew members and scattering debris across Texas and Louisiana.