Fault Tree Analysis (FTA) is a method to discover the root causes of failures or potential failures. It starts with a top-level event like a service outage and works downward to identify all contributing faults and causes. FTA uses a fault tree diagram and 6 simple steps: 1) select a top event, 2) identify faults, 3) list causes, 4) use logic gates, 5) identify root causes, 6) list countermeasures. FTA helps prevent problems by identifying their root causes and countermeasures to address them. While powerful, FTA requires only paper, pencil and knowledge of the system to perform and can help teams resolve issues.
FAULT TREE ANALYSIS (FTA) SEMINAR PRESENTATIONOrange Slides
Fault tree analysis is a method to analyze the failure of a particular product or system through boolean logic technique. It is widely used by the Safety engineers and Reliability engineers.
FAULT TREE ANALYSIS (FTA) SEMINAR PRESENTATIONOrange Slides
Fault tree analysis is a method to analyze the failure of a particular product or system through boolean logic technique. It is widely used by the Safety engineers and Reliability engineers.
Slate: A Centralized Clearance Search Management SystemGreyB
You would have heard of an old proverb - “an ounce of prevention is worth a pound of cure”. This fits seamlessly in context with ‘Freedom to Operate’ studies (considering ideal results). However there’s always a margin for errors and considering the significance of FTO searches, the fear of litigation is always prevalent. Therefore, you need to be prepared with the defenses, evidences and arguments at your end.
This is where Slate comes in.
Title Networking Essentials Companion GuideAuthor Cisco NetworkingTakishaPeck109
Title: Networking Essentials Companion GuideAuthor: Cisco Networking AcademyPUBLISHED BY: Cisco PressPUBLICATION DATE: March 2022PRINT LENGTH:544 pagesChapter 20Troubleshoot Common Network Problems
Objectives
Upon completion of this chapter, you will be able to answer the following questions:
· What are some of the approaches used to troubleshoot networks?
· What is the process of detecting physical layer problems?
· What network utilities can you use to troubleshoot networks?
· How do you troubleshoot a wireless network problem?
· What are some common Internet connectivity problems?
· What outside sources and Internet resources are available for troubleshooting?
Key Terms
There are no key terms in this chapter.
Introduction (20.0.1)
Congratulations! You‛ve made it to the final chapter in Networking Essentials. While learning about networking in this course, you‛ve likely developed skills you didn‛t even know you needed. Was the purpose of this whole course learning how to set up a simple network? Of course, network setup is important, but it‛s just part of your learning.
What do you do when your network doesn‛t work? This is your real test as a network administrator—to be able to figure out what is wrong, fix it, (and here‛s the tricky part) and not accidentally create a whole new problem. Get good at troubleshooting, and you will always be in demand.
The Troubleshooting Process (20.1)
Troubleshooting is the process of identifying, locating, and correcting problems. Experienced individuals often rely on instinct to troubleshoot. However, you can use structured techniques to determine the most probable cause and solution to problems.Network Troubleshooting Overview (20.1.1)
When troubleshooting, you must maintain proper documentation. This documentation should include as much information as possible about the following:
· The problem encountered
· Steps taken to determine the cause of the problem
· Steps to correct the problem and ensure that it will not reoccur
You must document all steps taken in troubleshooting, even the ones that did not solve the issue. This documentation becomes a valuable reference should the same or a similar problem occur again. Even in a small home network, good documentation saves hours of trying to remember how a problem was fixed in the past.Gather Information (20.1.2)
When a problem is first discovered in the network, it is important to verify the problem and determine how much of the network is affected by it. After the problem is confirmed, the first step in troubleshooting is to gather information. The following checklist provides some of the important information you should check:
· Nature of Problem
· End-user reports
· Problem verification report
· Equipment
· Manufacturer
· Make/model
· Firmware version
· Operating system version
· Ownership/warranty information
· Configuration and Topology
· Physical and logical topology
· Configuration files
· Log files
· Previous Troubleshooting
· Steps taken
· Res ...
Metric Abuse: Frequently Misused Metrics in OracleSteve Karam
This is a presentation I created for RMOUG 2014 which I was sadly unable to attend. However, I wanted to share it with the Oracle community so that you can learn a bit about metrics that are frequently cited, frequently demonized, and frequently misused. In this deck we will go through the steps to diagnose issues and what NOT to blame as you go through the process.
The topics and concepts discussed here were originally formed in a blog post on the OracleAlchemist.com site: http://www.oraclealchemist.com/news/these-arent-the-metrics-youre-looking-for/
What do you do when you’ve caught an exception?Paul Houle
This article is a follow up to “Don’t Catch Exceptions“, which advocates that
exceptions should (in general) be passed up to a “unit of work”, that is, a fairly
coarse-grained activity which can reasonably be failed, retried or ignored. A unit of
work could be:
an entire program, for a command-line script,
a single web request in a web application,
the delivery of an e-mail message
the handling of a single input record in a batch loading application,
rendering a single frame in a media player or a video game, or
an event handler in a GUI program
The code around the unit of work may look something like
[01] try {
[02] DoUnitOfWork()
[03] } catch(Exception e) {
[04] ... examine exception and decide what to do ...
[05] }
For the most part, the code inside DoUnitOfWork() and the functions it calls tries to
throw exceptions upward rather than catch them.
To handle errors correctly, you need to answer a few questions, such as
Was this error caused by a corrupted application state?
Did this error cause the application state to be corrupted?
Was this error caused by invalid input?
What do we tell the user, the developers and the system administrator?
Could this operation succeed if it was retried?
Is there something else we could do?
Although it’s good to depend on existing exception
IT Service Management (ITSM) Model for Business & IT AlignementRick Lemieux
Today’s multi-faceted business world demands that Information Technology provide its services in the context of a fully integrated corporate strategic model. This transformation becomes possible when IT evolves from its technological heritage into a Business Technical Organization, or an “internal service provider.” This paper describes how the itSM Solutions reference model integrates five widely used service management domains to create a powerful model to guide IT in its journey into the business leadership circle.
Slate: A Centralized Clearance Search Management SystemGreyB
You would have heard of an old proverb - “an ounce of prevention is worth a pound of cure”. This fits seamlessly in context with ‘Freedom to Operate’ studies (considering ideal results). However there’s always a margin for errors and considering the significance of FTO searches, the fear of litigation is always prevalent. Therefore, you need to be prepared with the defenses, evidences and arguments at your end.
This is where Slate comes in.
Title Networking Essentials Companion GuideAuthor Cisco NetworkingTakishaPeck109
Title: Networking Essentials Companion GuideAuthor: Cisco Networking AcademyPUBLISHED BY: Cisco PressPUBLICATION DATE: March 2022PRINT LENGTH:544 pagesChapter 20Troubleshoot Common Network Problems
Objectives
Upon completion of this chapter, you will be able to answer the following questions:
· What are some of the approaches used to troubleshoot networks?
· What is the process of detecting physical layer problems?
· What network utilities can you use to troubleshoot networks?
· How do you troubleshoot a wireless network problem?
· What are some common Internet connectivity problems?
· What outside sources and Internet resources are available for troubleshooting?
Key Terms
There are no key terms in this chapter.
Introduction (20.0.1)
Congratulations! You‛ve made it to the final chapter in Networking Essentials. While learning about networking in this course, you‛ve likely developed skills you didn‛t even know you needed. Was the purpose of this whole course learning how to set up a simple network? Of course, network setup is important, but it‛s just part of your learning.
What do you do when your network doesn‛t work? This is your real test as a network administrator—to be able to figure out what is wrong, fix it, (and here‛s the tricky part) and not accidentally create a whole new problem. Get good at troubleshooting, and you will always be in demand.
The Troubleshooting Process (20.1)
Troubleshooting is the process of identifying, locating, and correcting problems. Experienced individuals often rely on instinct to troubleshoot. However, you can use structured techniques to determine the most probable cause and solution to problems.Network Troubleshooting Overview (20.1.1)
When troubleshooting, you must maintain proper documentation. This documentation should include as much information as possible about the following:
· The problem encountered
· Steps taken to determine the cause of the problem
· Steps to correct the problem and ensure that it will not reoccur
You must document all steps taken in troubleshooting, even the ones that did not solve the issue. This documentation becomes a valuable reference should the same or a similar problem occur again. Even in a small home network, good documentation saves hours of trying to remember how a problem was fixed in the past.Gather Information (20.1.2)
When a problem is first discovered in the network, it is important to verify the problem and determine how much of the network is affected by it. After the problem is confirmed, the first step in troubleshooting is to gather information. The following checklist provides some of the important information you should check:
· Nature of Problem
· End-user reports
· Problem verification report
· Equipment
· Manufacturer
· Make/model
· Firmware version
· Operating system version
· Ownership/warranty information
· Configuration and Topology
· Physical and logical topology
· Configuration files
· Log files
· Previous Troubleshooting
· Steps taken
· Res ...
Metric Abuse: Frequently Misused Metrics in OracleSteve Karam
This is a presentation I created for RMOUG 2014 which I was sadly unable to attend. However, I wanted to share it with the Oracle community so that you can learn a bit about metrics that are frequently cited, frequently demonized, and frequently misused. In this deck we will go through the steps to diagnose issues and what NOT to blame as you go through the process.
The topics and concepts discussed here were originally formed in a blog post on the OracleAlchemist.com site: http://www.oraclealchemist.com/news/these-arent-the-metrics-youre-looking-for/
What do you do when you’ve caught an exception?Paul Houle
This article is a follow up to “Don’t Catch Exceptions“, which advocates that
exceptions should (in general) be passed up to a “unit of work”, that is, a fairly
coarse-grained activity which can reasonably be failed, retried or ignored. A unit of
work could be:
an entire program, for a command-line script,
a single web request in a web application,
the delivery of an e-mail message
the handling of a single input record in a batch loading application,
rendering a single frame in a media player or a video game, or
an event handler in a GUI program
The code around the unit of work may look something like
[01] try {
[02] DoUnitOfWork()
[03] } catch(Exception e) {
[04] ... examine exception and decide what to do ...
[05] }
For the most part, the code inside DoUnitOfWork() and the functions it calls tries to
throw exceptions upward rather than catch them.
To handle errors correctly, you need to answer a few questions, such as
Was this error caused by a corrupted application state?
Did this error cause the application state to be corrupted?
Was this error caused by invalid input?
What do we tell the user, the developers and the system administrator?
Could this operation succeed if it was retried?
Is there something else we could do?
Although it’s good to depend on existing exception
IT Service Management (ITSM) Model for Business & IT AlignementRick Lemieux
Today’s multi-faceted business world demands that Information Technology provide its services in the context of a fully integrated corporate strategic model. This transformation becomes possible when IT evolves from its technological heritage into a Business Technical Organization, or an “internal service provider.” This paper describes how the itSM Solutions reference model integrates five widely used service management domains to create a powerful model to guide IT in its journey into the business leadership circle.
1. Fault Tree Analysis Made Easy
The workable, practical guide to Do IT Yourself
Page 1 of 2
Vol. 4.47 • November 26, 2008
Fault Tree Analysis Made Easy
By Hank Marquis
Hank is EVP of Knowledge Management at Universal Solutions Group, and Founder and Director of NABSM.ORG. Contact Hank by email at
hank.marquis@usgct.com. View Hank’s blog at www.hankmarquis.info.
I f you are ITIL certified, you’ve heard of Fault Tree Analysis, or FTA. But if you’re like most, you
probably have no idea how to actually perform or use FTA!
Simply put, FTA is a method for discovering the root causes of failures or potential failures. FTA then helps
you understand how to fix or prevent the failure.
FTA is an analysis that starts with a top-level event, like a service outage. You then work it downward to evaluate all the
contributing faults, and the causes of faults, that may ultimately lead (or have led) to its occurrence. You use the fault
tree diagram to identify countermeasures to eliminate the causes of the failure.
FTA requires nothing more complex than paper, pencil, and an understanding of the service at hand. You will need
accurate Configuration Information (CI) contextual information in order to get the most value from FTA. The following 6
simple steps can help you resolve tough design issues or problems quickly and easily.
1. Select a top level event for analysis. Try to be specific, for example, “Email server down for more than 4 hours.”
Sources of top level events include:
a. Problem/Known Error Records
b. Service Outage Analysis (SOA)
c. Potential failures from brainstorming and a Technical Observation Post (TOP)
d. “What-if” scenarios based on Service Level Agreements, etc.
2. Identify faults that could lead to the top level event. Continuing the above example, some possible faults leading to
an outage lasting more than 4 hours might be “loss of power,” another might be “hardware failure.” List all the faults
under the top-level event in boxes and connect the fault boxes to the top-level event box by drawing lines.
3. For each fault, list as many causes as possible in boxes below the related fault. Continuing the example above, in the
case of “loss of power,” some causes might be “electrical outage,” “power supply failure,” and so on. Connect the boxes
to the appropriate fault box.
4. Two logic operators – And and Or, also known as logic gates – are used to represent the sequencing of faults and
causes. For example, “Email server down for more than 4 hours” could be caused by “loss of power” Or “hardware
fault.” Another might be “loss of building power” And “battery backup exhausted.” Update faults and causes by
grouping logically related items using And or Or between faults and events; and faults and causes. Re-draw the lines
from top-level event to logic gates to faults to logic gates to causes. The result is a graphical fault tree diagram as
follows:
http://www.itsmsolutions.com/newsletters/DITYvol4iss47.htm
11/25/2008