Podcasts about mtbf

MTBF and an Indicator Abstract Chris and Fred discuss Key Points Join Chris and Fred as they discuss Topics include: point 1 point 2 point 3 Enjoy an episode of Speaking of Reliability. Where you can join friends as they discuss reliability topics. Join us as we discuss topics ranging from design for reliability techniques […] The post SOR 1024 MTBF and an Indicator appeared first on Accendo Reliability.

Welcome back to the Reliability Leader Podcast! In this episode, I'm talking about Mean Time Between Failure (MTBF), a number we use a lot but might not actually need. MTBF sounds useful, but it often just creates more questions than answers. I'll share why we still use it, the problems it can cause, and some simpler ways to measure success. Listen now! #reliabilityleader #betterchoices #futureofwork #podcast

This week host @Jackgreenstalk (aka @Jack_Greenstalk on X/instagram backup account) [or contact via email: JackGreenstalk47@gmail.com] is joined by the always amazing panel with @spartangrown on instagram only or email spartangrown@gmail.com for contacting spartan outside social media, any alternate profiles on other social medias using spartan's name, and photos are not actually spartan grown be aware, @TheAmericanOne on youtube aka @theamericanone_with_achenes on instagram who's amy aces can be found at amyaces.com and @Zenthanol on youtube who offers IPM direct chat for $1 a month on patreon.com/zenthanol , ... This week we missed @NoahtheeGrowa on instagram , @drmjcoco from cocoforcannabis.com as well as youtube where he tests and reviews grow lights and has grow tutorials and @drmjcoco on instagram, Matthew Gates aka @SynchAngel on instagram and twitter and @Rust.Brandon of @Bokashi Earthworks who's products can be found at bokashiearthworks.com and @ATG Acres Aaron The Grower aka @atgacres his products can be found at atgacres.com and now has product commercially available in select locations in OK, view his instagram to find out details about drops! for Jacks books and seeds checkout www.50strains.com tonight we answered the following questions, Minnesota Grower​​ asked "@CheapHomeGrow how does an LED light bar usually fail? Does it dim or just go dark? MTBF? Wondering when to have a spare on deck." @CheapHomeGrow MTBF Mean Time Before Failure thanks much DONKEY_POPULOUS​​ asked "@CheapHomeGrow… I'm currently running in 2 3x3s using 4earthboxs. I want to hunt through some reg seeds, wanted to hear your thoughts on running more then a single plant per earthbox! Any drawbacks?" DONKEY_POPULOUS​​At asked "what point would you suggest to take clones before an early flip?" Chefomj ​​I said "I have a question… @jackgreenstalk do cannabis plants have the ability to mimic? Ie like orchids." apm ​​ asked "@Cheaphomegrow sup guys I have a grow question but non cannabis. Does the pollen of fruit and vegetables become non viable after getting wet? Like canna pollen?" --- Support this podcast: https://podcasters.spotify.com/pod/show/cheaphomegrow/support

Send us a textUnlock the secrets to safeguarding your organization's most sensitive data and enhance your cybersecurity acumen. Join us on the CISSP Cyber Training Podcast as I, Sean Gerber, break down the critical importance of managing secrets within popular collaboration tools like Slack, Jira, and Confluence. Discover practical methods such as real-time monitoring and swift remediation to secure API keys and encryption tokens. Learn how fostering a culture of security awareness through educational initiatives can significantly mitigate risks and enhance overall security posture.Next, we turn our attention to data sanitization and media destruction—essential processes for maintaining confidentiality and regulatory compliance. I'll guide you through various methods of data sanitization and media destruction, from degaussing to shredding and pulping, while also demystifying the concepts of MTBF and MTTF. We'll delve into the challenges of data classification and the importance of proper data labeling. Whether you're prepping for the CISSP exam or simply looking to deepen your cybersecurity knowledge, this episode is rich with actionable insights and expert guidance. Tune in and elevate your cybersecurity skills to the next level!Gain access to 60 FREE CISSP Practice Questions each and every month for the next 6 months by going to FreeCISSPQuestions.com and sign-up to join the team for Free. That is 360 FREE questions to help you study and pass the CISSP Certification. Join Today!

Send us a textWhat if AI could be your company's best asset—and its biggest risk? Join me, Sean Gerber, on this enlightening episode of the CISSP Cyber Training Podcast, where we journey through the essentials of cybersecurity with a particular focus on media protection techniques from Domain 7.5 of the CISSP ISC² training manual. We'll also navigate the secure-by-design principles crucial in the age of artificial intelligence. With AI transforming large enterprises, I'll share eye-opening statistics on its adoption and delve into the risks it brings, such as cloud misconfigurations leading to severe breaches. Plus, we'll discuss the alarming rise of deepfake scams with a real-world example that shook a UK energy firm to its core.Ever wondered how to choose the best data encryption method for your needs? This episode has got you covered! We'll discuss various encryption techniques like AES, RSA, and ECC, and why it's essential to select the right one based on media type. Trust me, understanding key management and rotation is vital for maintaining data integrity, especially when dealing with cloud storage and third-party providers. I'll also walk you through secure erasure methods, from the DOD 5220.22-M standard to physical destruction techniques like shredding and degaussing, ensuring your data truly becomes irretrievable.Lastly, don't miss our deep dive into mobile device protection. I'll highlight the critical software and physical security measures necessary to defend your devices against threats, emphasizing the importance of regular updates and robust antivirus solutions. We'll explore strategies for data encryption, backup, and recovery, and clarify the differences between MTBF and MTTF and their relevance to your systems. Wrapping up with the environmental factors affecting device usage and data management, this episode is packed with actionable insights to elevate your cybersecurity game. Tune in now to arm yourself with the knowledge necessary to protect your digital world!Gain access to 60 FREE CISSP Practice Questions each and every month for the next 6 months by going to FreeCISSPQuestions.com and sign-up to join the team for Free. That is 360 FREE questions to help you study and pass the CISSP Certification. Join Today!

Benvenuti a tutti i TL e bentornati su questo canale! Siamo alla puntata numero 67, e oggi vedremo alcune informazioni, per lo più tecnologiche. Parleremo degli abbonamenti di Autodesk Fusion, con un focus particolare su quelli dedicati agli hobbisti e ai freelance. Inoltre, non mancheranno le CAD Pillz, che erano assenti nell'episodio precedente a causa di problemi di tempo. Oggi le ritroveremo e saranno davvero interessanti. Che ne dite, iniziamo? Forza, diamo fuoco alle polveri! Istruzioni per installare Autodesk Fusion per hobbysti In breve, una volta effettuato l'accesso in fondo a questa pagina:
https://www.autodesk.com/campaigns/fusion-360-for-hobbyists
viene visualizzato un collegamento che dice “Inizia”. Quando fai clic su quel collegamento, il tuo account verrà automaticamente assegnato al nuovo abbonamento per uso personale. Quindi avvia un download. Se hai già installato Fusion 360 puoi ignorare il download, senza bisogno di reinstallarlo. Nota, potrebbero esserci fino a 30 minuti di ritardo prima che il nuovo abbonamento sia visibile nella tua installazione Fusion 360 esistente. [CAD Pilz] Come utilizzare lo strumento di configurazione della vista SOLIDWORKS PDM Creazione di nuovi utenti PDM Che cosa sono i controlli delle regole di progettazione nella progettazione di PCB? Sistemi meccatronici indossabili per la misura di parametri biomeccanici: il progetto “STARDUST” La previsione della vita utile dell'acciaio AISI 316L La prima auto elettrica solare Il TiraLinee è un podcast indipendente realizzato da Daniele Borghi, se vuoi metterti con contatto con me, mi potete trovare qui: my social bio La mia attrezzatura ► Mic: Focusrite DM1 ► Scheda: Focusrite Vocaster One ► Software: Reaper - Ulti.Media Converter 2 thks Alex Raccuglia ► Cuffie: Focusrite HP60v Le musiche sono state create con Tuney Le cover sono state create con Image Creator by Microsoft Designer

edX ✨I build courses: https://insight.paiml.com/d69  

MTBF, Really? Abstract Chris and Fred discuss the MTBF … again. And again. People don’t (want to) get it. So here we go again … Key Points Join Chris and Fred as they discuss the MTBF and why it should virtually never be used. Why? Topics include: What’s wrong with the MTBF when it comes […] The post SOR 965 MTBF, Really? appeared first on Accendo Reliability.

Renita and I had a blunt discussion about what to look out for when evaluating a course offered by a tech job influencer. We discussed our perspectives on what we uncovered during our research for this episode. We also discussed some trustworthy courses and programs if you are looking for training.  You can reach out to either one of us at https://www.tekordie.com/contact/ if you have any questions, comments, etc. Renita Rhodes is a Vice President, Audit Manager in Cyber Security for a well-known worldwide bank, supporting the coverage of the bank's core Cybersecurity controls. She supports coverage in areas such as - Cyber Threat Fusion Center, - Data Loss Protection,- Security Information and Event Management, - Cryptographic Services, and - Network Security Management.Renita also works as a Cybersecurity and Information Systems Adjunct Professor at Maryville University and Harris Stowe State University, teaching the; Cyber Law, Policy and Compliance, Security Information and Event Management, Introduction to Information Security, Applied Programming - Python and Systems Analysis and Design courses.

The Mean Time Between Failure (MTBF) appears in lots of textbooks and standards, so it must be really important ... right? Well, not really. The post The MTBF and Modeling System Reliability appeared first on Accendo Reliability.

This morning's email included a question on why I was so against using MTBF. This episode is my answer and why one should avoid MTBF The post Why You Should Avoid MTBF appeared first on Accendo Reliability.

Ever heard of the 'naked mole rat?' Probably not. It is perhaps the only mammal that never ages. Never gets old. So why do many reliability engineers and textbooks assume that most of our products and machines behave like 'naked mole rats?' The post SOR 885 Naked Mole Rat appeared first on Accendo Reliability.

If you want to learn more about MTBF testing and how it might (or might not) work ... then view this recording. The post How Do I Do MTBF Testing? appeared first on Accendo Reliability.

V podcastu se budu věnovat tématu Engineering metrik. Zaměříme na různé typy metrik, jako jsou produktové, procesní a projektové. Povíme si o metrikách, které jsou klíčové pro úspěšnou práci v oblasti inženýrského řízení. Mezi konkrétní metriky, které budeme řešit, patří feature to market, cycle time, velocity, sprint burndown, release cycle, code churn, MTTR, MTBF, supporting each other, rework ratio a wip balance. Dále se budeme věnovat 5 klíčovým praktikám, které jsou nezbytné pro úspěšné vedení týmu. Tyto praktiky jsou model the way, inspire and share the vision, challenge the process, enable others to act a encourage the heart.

We are often faced with vendors who have outrageous claims regarding the reliability of a component or product ... where we are underwhelmed with reliability test data? Particularly when there is zero failures ... and sometimes a lower confidence bound on the MTBF from this data? The post SOR 827 60th Percentile with Vendor Data appeared first on Accendo Reliability.

What happens when you (perhaps for the first time) realize that the MTBF is not reliability ... but you work in an organization or industry that appears to worship it? What can you do? The post SOR 802 How to Talk About MTBF appeared first on Accendo Reliability.

The Evil Ways of MTBF with Fred Schenkelberg It’s my pleasure to welcome Fred Schenkelberg back to the podcast. He is a reliability engineer and management consultant. In this episode we covered: What is MTBF? Why would people want to calculate what that average time between failure is or where did this come about? What […] The post 307 – The Evil Ways of MTBF with Fred Schenkelberg appeared first on Accendo Reliability.

Brendan Montima is three weeks into the "My Tech Best Friend" ServiceNow bootcamp and is already showcasing great work.  He's going to be a great addition to the ServiceNow world, and we got to interview him FIRST.   We talk...- The importance of DOING- How ServiceNow compares to learning other techs- What parts of the platform excite us- Myths and misconceptions about ServiceNowVery special thanks to our sponsor, ClearSkye the premiere ID Governance & Automation solution built natively on Servicenow.  Check out the episode we did with their VP of Engineering.   And Magic Mind, the world's first "productivity drink", and the cure to The Duke's 3pm crash.  Learn more about Magic Mind. ABOUT OUR GUESTSBrendan Montima is an aspiring ServiceNow Developer taking the MTBF bootcampALSO MENTIONED ON THIS EPISODEGo With the Flow - A Youtube playlist about ServiceNow Flow DesignerABOUT USCory and Robert are vendor agnostic freelance ServiceNow architects.Cory is the founder of TekVoyant.Robert is the founder of The Duke Digital MediaSponsor Us!

The Mean Time Between Failure (MTBF) is not reliability - but is often treated as if it is. So sometimes we are handed lots of MTBF values for different components of our system, and are told to somehow create a reliability estiamte. So what do you do? The post SOR 699 Only have MTBFs appeared first on Accendo Reliability.

When is MTBF OK? Abstract Chris and Fred discuss the MTBF … and if and when it can be used … sometimes in reliability engineering. We know that the MTBF is one of the most chronically overused (and misused) so-called ‘reliability’ metrics. But is there scope for it to be used … sometimes? Key Points […] The post SOR 688 When is MTBF OK? appeared first on Accendo Reliability.

In this episode, we connect with Sam Russem of system integration firm Grantek to better understand Meantime to Repair (MTTR) and Meantime Before/Between Failure (MTBF). We explore how these metrics are applied and calculated and how they can benefit manufacturing operations.

技術顧問の和田卓人さんと、Four key metricsの計測、技術と経営の接続、Team Topologiesなどについて話しました。 Show Notes: ピクスタ技術ブログ「てくすた」 パーフェクトRuby on Rails【増補改訂版】 LeanとDevOpsの科学 2020 State of DevOps Report CTOとして招聘されて1年でDX Criteriaを大幅改善するために追求した唯一の成果指標 Agile & Lean Metrics: Cycle Time Backlog Pivotal Tracker Jira Software DORA joins Google Cloud https://cloud.google.com/devops Nicole Forsgren Insights: Engineering Leader and Organizational DORA Reports · Issue #127 Four Keys 〜自分たちの開発レベルを定量化してイケてる DevOps チームになろう〜 CTOの頭の中：技術投資を最適化する 財務3表一体理解法 カナリアリリース MTTD vs MTTF vs MTBF vs MTTR Service-level objective PRINCIPLES OF CHAOS ENGINEERING Chaos Engineering に向けてレシピサービスの Steady State を追求する d/d/d Full Cycle Developers at Netflix — Operate What You Build Team Topologies QRC Team Topologies-ja Value stream Team Topologiesを読んだ

This podcast is in response to a question one of our listeners asked us! If we have allocated reliability goals (or even MTBF goals) to our subsystems or components, then how do we make sure they are on track? Is testing the answer? If not, what is? Listen to this podcast to learn more. The post SOR 619 Is Testing The Only Way to Confirm Reliability appeared first on Accendo Reliability.

Vendor MTBF Claim Abstract Philip and Fred discussing Key Points Join Philip and Fred as they discuss Topics include: point 1 point 2Vendor MTBF Claim point 3 Enjoy an episode of Speaking of Reliability. Where you can join friends as they discuss reliability topics. Join us as we discuss topics ranging from design for reliability […] The post SOR 611 Vendor MTBF Claim appeared first on Accendo Reliability.

We continue on with SSDs! SSDs and why you want one – Part 2 This is the alphabet soup segment as we talk about SLC, MLC, eMLC, MTBF, and more! SSD Reliability: Can You Really Rely on Your SSD? (wepc.com) SSD Lifespan: How Long Will Your SSD Work? (enterprisestorageforum.com) Do this to increase your SSD’s lifespan! – CNET SSD optimization in Windows 10 (pugetsystems.com) How to achieve the best transfer speeds with external drives | AKiTiO

MTBF represents the reliability of the equipment/machine. For the value of the MTBF, the longer, the better. I would like to explain how this MTBF computes. 

MTBF, Reliability, and the Curve Abstract Kirk and Fred discussing how testing a small sample size of a new product results on a larger margin of error for the larger population. Key Points Join Kirk and Fred as they discuss all the factors that go into making reliability estimates from the testing of samples and […] The post SOR 591 MTBF, Reliability, and the Curve appeared first on Accendo Reliability.

Baixe gratuitamente o e-book: Como implantar um PCM do zero, clicando em www.manutencaoemacao.com.br

What are the New Challenges in Reliability Engineering? Abstract Kirk and Fred discussing the new challenges in reliability engineering, which maybe the old challenges of moving away from the misleading approach of Failure Prediction Methodology (FPM) and for Fred its the continued use of MTBF as a metric for reliability. Key Points Join Kirk and […] The post SOR 562 What are the New Challenges in Reliability Engineering? appeared first on Accendo Reliability.

Episode 45: A Conversation with Dr. Chris Jackson About ReliabilityDr. Chris Jackson discusses reliability and his five-part article series entitled "3 Ways to do Reliability Allocation."Dr. Chris Jackson is the founder of Acuitas, a company dedicated to reliability. Chris founded Acuitas in 2010. He was awarded his mechanical engineering degree from the University of New South Wales, and has since receive a Masters in PhD in Reliability Engineering from the University of Maryland. He is an American Society of Quality Certified Reliability Engineer (CRE), and a Chartered Professional Engineer (CPEng) from Engineers Australia.​He has been the Senior Reliability Engineer for the Australian Defence Force, and has been the director and founder of multiple research centers at the University of California Los Angeles. He has authored or co-authored multiple textbooks on reliability engineering and implemented several RAM programs across multiple industries. During the interview, Chris discusses his five-part article entitled "3 Ways to do Reliability Allocation." This article may be viewed here:https://accendoreliability.com/?s=3+Ways+to+do+Reliability+AllocationAdditional technical works by Dr. Jackson may be viewed here:https://accendoreliability.com/page/2/?s=jacksonDr. Jackson's book "Reliability Engineering and Management" may be purchased here:https://www.amazon.com/Reliability-Engineering-Management-Christopher-Jackson-ebook/dp/B071LGDYQGDr. Jackson may be reached here:chris.jackson@acuitas.com

What to Do About MTBF Use podcast episode with speaker Fred Schenkelberg While the NoMTBF movement is making progress, we still find those that seem to want to use MTBF (or MTTF). As you know, MTxx type metrics are means, they contain little information and are generally misunderstood and misused. So, what should a well-educated […] The post What to Do About MTBF Use appeared first on Accendo Reliability.

SOR 504 Eradication of MTBF Abstract Fred discussing just how bad MTBF and related measures are for our profession. Key Points Join Carl and Fred as they discuss Topics include: The rampant misunderstanding of what it means Why this is a problem and what we can do about it What you can do to avoid […] The post SOR 504 Eradication of MTBF appeared first on Accendo Reliability.

The Personal Computer Show Wednesday September 11th 2019 PRN.fm Streaming On the Internet 6:00 PM Eastern Time September 11th Remembrance IN THE NEWS • Apple just unveiled the iPhone 11 • The MTA is tired of saving AirPods from subway tracks • Google just released Android 10 • Google Insider Turns Over Docs And Laptop To DOJ • Steve Wozniak “Give me a choice to pay for almost no tracking.” FEATURE SEGMENTS Computer Talk – Benjamin Rockwell • IT Pro Series – Duty cycles, MTBF, failures cycles From the Tech Corner – Hank Kee • COBOL Turns 60 • 17 Things You Can Do in Android 10 Home Automation – Marty Winston • Home Automation for Cheapskates

This week, I welcome Fred Schenkelberg back to the show to talk about mean time between failures and the basics of reliability math. Long story short, I hope you're not using MTBF as a proxy for reliability! Thank you for listening and if you enjoy the show, please subscribe to Rob's Reliability Project on your favourite podcast platform and share it with your colleagues. You can also follow Rob's Reliability Project on LinkedIn and Facebook and check out robsreliability.com as well. If you're looking for a shorter tip, subscribe to Rob's Reliability Tip of the Day on your favorite podcast platform or on your Amazon Alexa as a Flash Briefing. Finally, if there are any topics, guests you'd like to hear from, questions you want answered, or if you'd like to appear on the podcast, email me at robsreliabilityproject@gmail.com Follow Rob's Reliability Project on LinkedIn - https://www.linkedin.com/company/robsreliabilityproject/ Follow Rob's Reliability Project on Facebook - https://www.facebook.com/robsreliabilityproject/ Music by XTaKeRuX, Song: White Crow is licensed under a Creative Commons 4.0 Attribution License.

What You Need to Know About MTBF podcast episode with speaker Chris Jackson MTBF stands for mean time between failure. This sounds intuitively easy to understand. But if you haven t taken the time to understand MTBF, and your organization relies on the reliability of its products, you are almost certainly in trouble. For example, […] The post What You Need to Know About MTBF appeared first on Accendo Reliability.

Today we talk to Yizhak Bot who started his career in the Israeli DOD, and today he will share with us what derating is and how you can work on the schematic level with their simulation software to eliminate field failures. With a background including about ten years working with the reliability of very big systems gaining much insight into how systems work and fail, Yizhak is an expert you’ll want to listen in and learn from. Today he is the founder and CTO of BQR Reliable Engineering. Show Highlights: Yizhak was a sponsor at both previous AltiumLive conferences and at the most recent, he spoke about the technology that BQR offers to engineers who lay out boards. A few common design errors that lead to field failures are: 1. Sudden CPU reboots, for example in aircraft - imagine an in-flight computer failure. 2. With safety- and non-safety functions together on one board, the non-safety functions will affect the safety functions - they need to be separated. 3. If you have a DC to DC converter - you’ll want to test if the voltage is correct and remember to connect them to the same ground, in the field it can be difficult to establish where the problem originates. What is derating as discussed at AltiumLive? You cannot use any component, current, or junction temperature running at its maximum rating; you must derate it. Integration, quality and field tests cannot find all failures that may occur because you cannot test all the combinations; using the simulation tool ensures your design is robust. Tell us about Fixstress and what inspired you to develop it? We wanted to find something to check for issues before products are in the field. We developed a tool that calculates stress levels of components, and a schematic review which detects design errors. Additionally, the simulation can do a thermal analysis and MTBF prediction to complete the analysis for the designer. What is the impact on your customers when using Fixstress? Almost zero failures in the field leading to the longevity of products. What kind of applications do you address and in which geographic regions? Mostly in big systems such as aerospace, also trains, automotive, shipping, telecoms, gas and oil, server farms, wind farms, power distribution. Our geographic market reach currently is the USA, Canada, Brazil, Europe, UK, Sweden and the Netherlands as well as China, Singapore, Japan and starting to work in Korea. Most of our growth is due to mouth-to-mouth referrals and clients asking sub-contractors to use the technology.     Links and Resources: BQR Reliable Engineering

Bob chats with Microsoft Azure DevOps Product Owner and author of Agile Software Engineering with Visual Studio, Sam Guckenheimer, at the DevOps Enterprise Summit 2018. Connect with Sam and Bob on Twitter.   Transcript Sam Guckenheimer ‑ DevOps Enterprise Summit 2018 Bob Payne:  "The Agile Toolkit." [music] Bob:  Hi, I'm your host Bob Payne. I'm here at the DevOps Enterprise Summit 2018 with Sam Guckenheimer. Welcome, Sam. Sam Guckenheimer:  Thank you, Bob. It's great to be here. Bob:  It's the first time we're really chatting. We chatted a tiny bit last night. My colleague Sanjiv Augustine said you were instrumental in hosting The Agile leadership network when it formed and came up with the declaration of Interdependence. How did that end up coming about? Sam:  Well, that was no what 14 years ago or something like that. [laughter] Sam:  What we saw was at that time that this was of course way pre‑DevOps. The Agile community had fractured into many groups saying "More agile than thou." That seemed stupid. Bob:  That fracturing has continued and remains as stupid today or... [laughs] Sam:  Yes. Unfortunately, the fracturing has continued and it hasn't gotten less stupid. That was the reason for trying to get the interdependence declaration together to get these leading lights from what was then the Agile community working together. In the meantime, the pure Agile has largely been eclipsed by DevOps. As you see something like this DevOps Enterprise Summit going on its fifth year roughly doubling every year in scale. I'm here now. Still there. [laughter] Bob:  There are a number of things that I found at this conference that I haven't been able to make a ton of sessions because we have a booth. I've found that I haven't really learned, maybe this is my own fault, anything at the Agile conferences for probably about 10 years. It wasn't any substantially interesting information. Sam:  That's correct. I last keynoted at the Agile conference in 2014. That's probably the last time I've been there. It got kind of stale. The energy in innovation, in practice I think has really shifted to DevOps. That's come about, because the DevOps' definition of Dunn is not potentially shippable and promotes... [crosstalk] Bob:  It's captured a value, enlargement value. Sam:  It's live in production with Telemetry that is demonstrating the value delivered. Going from a world where you were effectively stopping at an intermediate activity that didn't reach the customer or end‑user to go to one where you have to reach the end‑customer and you have to measure the value delivered, is much, much more powerful for all the stakeholders, for the business, for the people involved. It's much more satisfying. You disintermediate the development to customer relationship. You think of things as one engineering discipline, not as silos post the Scrums, so to speak. Bob:  Certainly there were a number of great Agile teams and organizations that fully believed that Dunn meant in the hands of customers and delivering whatever goal, that... [crosstalk] Sam:  I do not mean to bash anyone. I certainly think there great Agile teams. A lot of what we do today has its roots in extreme programming, but things like XP at the time, had this notion of, for example, pair programming. We have largely, as a community, moved to the notion of a pull request as a virtual pair programming. We have moved from the idea of onsite customer to measuring customer impact, which isn't to say onsite customer is a bad idea, it's a great idea, it's a rarely achievable one. All of these seeds that were planted back then in the late '80s by the early Agilists were important seeds. The garden where I think they're really bearing fruit now is in this DevOps community. Bob:  The other thing that I think is probably the next wave that we will see in organizations that are not already there, certainly, many organizations have already integrated business into this flow. Without that DevOps is necessary but not sufficient to actually change the outcomes that businesses are seeing. That's the next frontier for those companies that we're not sort of born in the world of IT as the fundamental driver of business outcomes. Sam:  That's correct. DevOps is the flip side of the coin from digital transformation. Digital transformation is the business term for taking your business model and turning it into one that can improve continuously in an Internet‑powered age. DevOps is the shorthand for the technical practices that enable that. Bob:  I see way too many organizations mistaking a DevOps transformation for digital transformation. They're fundamentally doing the DevOps practices, but they're not backing up into the initial value proposition to begin with. That will sort itself out. Sam:  This is a common thing of confusing means and ends. The ends are things around growing the business customer, acquisition customer, engagement customer, employee delight, all of these measures of happiness and success. The practices are ways of getting there. The goal is to focus however on those end results. The clear sign of dysfunction is when you see people measuring the inputs, not the outputs. Bob:  If Deming or [inaudible 7:33] came back and saw that Toyota was doing the same practices it was doing 75 years ago they would drop dead after having just come back to life. [laughs] In real systems the practices and the processes are never the ends. They are all in service of maximizing flow... [crosstalk] Sam:  Exactly. If you think about the evolution, the practices today are different because the constraints are different. One of the overriding constraints was for example infrastructure availability. You get all of the stuff around how to manage and schedule the infra. Today with the public cloud that constraint is gone. It's a classic example of, in Eliyahu Goldratt terms, elevating the constraint or removing the bottleneck. Then you see the constraint shifting. As you're adopting these practices what happens is you have a continual shift of the constraint, and you have the next one to attack the next bowling pin to knock down. [crosstalk] Sam:  Right. What DevOps says has basically taught us as well. You can remove infrastructure a constraint by using the cloud. You can focus on the value delivered to the customer and measure it so you can have both qualitative and quantitative view of that. You can take the quality game and shift it left and right so that quality does not become this big testing bottleneck in the middle. It can become part of the pull request flow. It can happen before code merges. Then you can in production gradually expose value to more and more of users so that the blast radius is something that's flexible, so you don't have the constraint of saying, "I need to master my MTBF in order to release." You can say, "I need to maximize my ability to recover and may have the shortest time to recover, so that by controlling the blast radius and being able to recover quickly I can experimentally by increasing the rate of experimentation I can deliver and measure value delivered on a cycle that was never possible in the old days." It wasn't possible before we had the Internet, it wasn't possible before it hit the public cloud, it wasn't possible before we had these practices of high‑quality, highly‑rugged automation that we do today. Bob:  Yeah it has been a sea change since I did Fortran on punch cards [laughs] . Sam:  There have been many sea changes yes. Mike Pearson gave a great talk yesterday, borrowing from Carlota Perez on the structure of industrial revolutions, and postulates that we're at the point of disruption from the period of adoption to the period of dispersion. That would account for a lot of the changes that we're seeing, and it would account for a lot of the anxiety that you see among people who are saying, "How do I learn fast enough? How do I catch up fast enough? How do I get ahead?" At the same time, what you see very clearly reflected in company success, company's market gap, and company's ability to innovate and pivot, is that the ones who have mastered the go‑fast‑without‑breaking‑things‑and‑adjust‑course‑as‑you‑go, are the ones that are winning in pretty much every sector. Bob:  I love Mark Schwartz's analogy of the battle of the Russians with Napoleon, and the speed of decision‑making being fundamentally out of sync with the reality of the battle. Sam:  Exactly, that was also true on Omaha beach in Normandy, that was true in Vietnam, that's been true in pretty much every military conflict, that the degree of autonomy and speed of innovation has determined the outcome in the end, and people who are great at enabling the next war instead of fighting the last ones, are the victors. The latest example decide or...I don't know if that's politically correct to go there, but you see it now in... Bob:  [laughs] That have been substantially politically correct on this podcast [laughs] . Sam:  You see this in cyber. The Russian budget for cyber is less than the cost of an F‑35. Bob:  No one could argue that the F‑35 is more costly than it needs to be but it's... [laughs] . [crosstalk] Sam:  Who cares? The point is, they're not trying to win the manned aerial dogfight. They are extending the notion of total war to a new battlefield and they've been very successful, but finding the place where there are no defenses and where it's possible to innovate quickly and it's proven to work. You could also argue that as David Sanger does in "The Perfect Weapon", that the US started this cyber‑war arms race. In any event, we've not follow through on the consequences of what we started. The military analogies, they turn some people off, but they have their value. We are, and the rest of society also, in a place where we need to be winning the future, not the past. Bob:  It's actually one of the analogies I quite often use when I'm talking to people that are OK with the military analogies. The OODA loop, the Boyd loop of observe‑orient‑decide‑act. The team that can turn that loop the fastest, whether it's Amazon, Netflix, or a manned‑aerial dogfight, or a cyber‑attack, is going to win. Sam:  Exactly. In our world, the OODA loop results in some kind of software or service delivered. One of the things we know from measuring it is that about a third of the time, we get the results we'd want, a third of the time, we get opposite result from what we hypothesized, and about a third of the time, it makes no difference. The implication of that is that you want to be able as quickly as possible, to double down on the successful third and fail fast or pivot away from the other two thirds, which means that you need to make the OODA loop as short as possible, which is what Boyd talked about in his idea of aircraft design and aerial battle. That's exactly true in how we develop and that means not just using small batches which Agile taught us. That means not just breaking down the silos, but it means really focusing on time to remediate and focusing on quality to the left so that you have clean delivery and you have the mechanism in production to control exposure and to go faster and wider as you need to. Bob:  You mentioned the one‑third, one‑third, one‑third, I know that was a study that came out in Microsoft. Actually... [crosstalk] Sam:  Ronick O' Harvey was behind that. Ronny is now a technical fellow, he wasn't back then. He basically took a very large sample of "improvements" that were delivered. Let's measure, are these really improving, what we wanted? The result was a third of the time, in other words, I've confirmed the others' change is bad, unless is great. That was quantitative demonstration of that. I don't know if he published that before he did a stand for PhD or after, but it was a famous study and it holds up. Bob:  I also very much like this idea of very small batches, because without the small batches, it's hard to get attribution of what improved the customer experience and what was neutral or negative, because you're conflating way too many changes if the batch is large. Sam:  That's why the pull request flows becomes successful, because you can make the pull request a batch that is a few lines of change, it's possible to have a human‑code review on it, and it's possible to have extensive automation on it. Again, an example of a practice that wouldn't have been possible pre‑cloud is when we do pull requests, we run the build‑in automation on them with typically 80‑some thousand tests before asking for the human‑code review. Human eyes are only focused on those things that automation has said looked good already. As opposed to the way things were done, pre‑cloud in the XP pair programming model, where human eyes were first defense. That was very appropriate given the constraints at the time. The constraints of today are different. Bob:  That was certainly one aspect of pairing. The other is just as the design discipline getting the collaborative design quite often yields better results, but... [crosstalk] Sam:  I totally think that people should collaborate on design. I'm totally for that. I'm not trying to.. Bob:  I totally get the point about the quality. Is automation...we want lazy engineers [laughs] . We want engineers focusing on creative thought, rather than repetitive action. Sam:  Exactly. Another example of that that's possible these days, is you want a very high reuse, an open source. If you can solve a problem with 30 lines of code and reuse thousands, that's much better than creating 3000 lines of codes that need to be maintained. In effect, we want to reward people for writing less code, which again turns on it's head, one of those classic input matrix and myths of, "Well, how much code did you write? How busy were you? How many hours did you put in?" As opposed to, "What result did you achieve?" Bob:  What are some DevOps practices that have really changed Microsoft fundamentally? I know you've got a couple of talks related to that here at the conference. Sam:  I bucket our lessons learned, usually in five groups. One is how we focus on value delivered to the customer, both quantitatively and qualitatively, and let that drive the way we think about what we're delivering and how we measure that. Two is how we apply production‑first mindset. Our CEO tends to call this a live‑site culture, in other words, you build it, you test it, you run it, you secure it, you troubleshoot it, you improve it with responsibility residing in you, the creating team, not getting fragmented across these Silos. Three is the idea of team autonomy and enterprise alignment that you want to let teams at the level of the feature crew Scrum, cream squad, whatever your favorite term is, you want to let these small feature crews work autonomously on their stuff, and control what they are taking into the next sprint or what items they're doing next. You want them to support their stuff in production and you want the mechanisms to align their work up to the common business results, so that they know which needles they need to move by the work that they do and they know how to view those gauges. The fourth is shifting quality left and right so that you can get a signal in the pipeline of green meaning green and red meaning red, and in production, you can see continually what is happening with every changes, you expand its exposure. Fifth finally is using cloud to make infrastructure‑flexible resource. That's how I bucket it. I did one talk yesterday with my friend Ellen Smith about how we moved our DevOps' ass. It's really a story about eight years of taking what's started as a non‑premise product and turning it into a cloud service and on‑premise product. That was an attempt to myth‑bust the idea that if you're going to the cloud, you need to start in the cloud and throw everything away. It was an attempt to say, "Here's a proof instance where we had a business, pre‑cloud, with on‑prem product. We preserve that and made it better, and use the same codebase to go the cloud where the cloud is making the on‑prem better." Of course the cloud's the majority of usage and the fastest growing now, but it wasn't a throwaway, which of that story. The other one which is similar, which I'm doing tomorrow, is a talk about Windows' journey to DevOps. Windows division is the extreme case of scale and legacy, and they have successfully moved to DevOps. There were a bunch of bumps along the way. For example, to get Windows to be able to use Git at their scale, we needed to fix the Git, and that took three attempts. Bob:  Really? Sam:  Yes. When we started doing something like a Git clone of the main Windows repo, took 12 hours. That was if the network didn't burp, or your laptop didn't go to sleep, or nothing else wrong happened. If any of those things did happen, then the whole operation needed to start over. Bob:  Need to start again, yeah. Sam:  That now takes a couple minutes. We did a series of 300x or better improvements in Git performance with what is now open‑sourced as the virtual file system for Git. Windows motivated all of that to be able to support their scale of codebase, which was hundreds of times larger than anything else anyone was using. Bob:  That's interesting. I did not know that you guys were major contributors to the Git. Sam:  We're one of the top two. We're the largest open‑source contributor of any company, have been for about two years now. Git is a project where we have been very heavily in, and virtual file system is one of the latest aspects of that. Come to the talk tomorrow. Bob:  OK, I may. What time is it? Sam:  11:25, I think? 11 something. The times here are weird. All these weird five‑minute increments. Bob:  [laughs] . It is five‑minute increments and three hours off, because I'm an East Coast person. Are you out of... [crosstalk] Sam:  Along Seattle. Bob:  Thank you so much, Sam. This has been great. Is there any one thing you'd like to close off with that you're interested in? Sam:  Yeah. There's something that I'd like to make our listener aware of, and that is I curate a website. The short link to it is aka.ms/DevOps. It's, DevOps and Microsoft. What I try to do is to put up our experience reports there, not the high‑level marketing level stuff, but like, "How did you actually do the change in testing? How did you go to no downtime deployments? How did you start using service reliability engineering? Etc." There're about 50 articles up there, but half of them with good video. They're just stories about how we work. I love people to use that as a... Bob:  As a resource? Sam:  ...open resource. Bob:  Thank you very much. It was very nice meeting you and chatting. Sam:  Thanks a lot, Bob. Bob:  Thanks. The Agile Toolkit Podcast is brought to you by LightSpeed. Thanks for tuning in. I hope you enjoyed today's show. If you'd like to give feedback or be on the show, you can ping me on Twitter. I am @AgileToolkit. You can also reach me at Bob.Payne@lithespeed.com. For more free resources, transcripts to the show, and information about our services, head over to LightSpeed.com. Thanks for listening. [music]  

In dieser Folge erfahren Sie alles über die verschiedenen Möglichkeiten, wie man zum Beispiel mithilfe von einem Festplattenverbund die Geschwindigkeit beschleunigt, die "mean time between failure" erhöht und welches Level für welchen Nutzen am besten ist. Viel Spaß beim Zuhören!

An unfortunate dementia incident You? You what? How was Mother's Day for everyone? We are sure nobody forgot... till we recorded this week's episode. Y1 apparently forgot about it. Yikes. Not sure if he is busy or if it's just dementia creeping up. Hear more about this unfortunate yet hilarious incident in this week's HAPAPAP Podcast Episode 50! What did we do the last week? ? Y1 Forgot about Mother's Day and died ? A1 Watched Prison's Playbook. Unexpectedly good Korean drama about prison life ⚾??‍♂️ Z1 Watched Wes Anderson's Isle of Dogs ?️?Recommended and of course better than the Mummy. News from our Google Feeeeeeeed ? New crowd levels display on MRT ?? Is there any use to this? Dementia drop-off points now available! ?????? Now we start to wonder if people will use this as a deposit centre for old people? Jupiter and Venus's gravity affect earth climate. Scientists stunned! ???‍???‍? Wow, so what the hell can we middle-classes do about it if even scientists are stunned? Word of the Week Bochup Hokkien. Nonchalant. Couldn't care less attitude. No fucks given. Usage This fella didn't even bother telling us he is not coming to the meeting. Simply bochup! Extra Word MTBF Mean Time Before Failure. Mean time between failures is the predicted elapsed time between inherent failures of a mechanical or electronic system, during normal system operation. MTBF can be calculated as the arithmetic mean time between failures of a system. (Taken from Wikipedia) One Last thing Every day can be a Mother's Day. It doesn't have to be on that Sunday ??‍♂️? https://www.instagram.com/p/Bi4aAmylAlA/?taken-by=hapapaplife

An unfortunate dementia incident You? You what? How was Mother's Day for everyone? We are sure nobody forgot... till we recorded this week's episode. Y1 apparently forgot about it. Yikes. Not sure if he is busy or if it's just dementia creeping up. Hear more about this unfortunate yet hilarious incident in this week's HAPAPAP Podcast Episode 50! What did we do the last week? ? Y1 Forgot about Mother's Day and died ? A1 Watched Prison's Playbook. Unexpectedly good Korean drama about prison life ⚾??‍♂️ Z1 Watched Wes Anderson's Isle of Dogs ?️?Recommended and of course better than the Mummy. News from our Google Feeeeeeeed ? New crowd levels display on MRT ?? Is there any use to this? Dementia drop-off points now available! ?????? Now we start to wonder if people will use this as a deposit centre for old people? Jupiter and Venus's gravity affect earth climate. Scientists stunned! ???‍???‍? Wow, so what the hell can we middle-classes do about it if even scientists are stunned? Word of the Week Bochup Hokkien. Nonchalant. Couldn't care less attitude. No fucks given. Usage This fella didn't even bother telling us he is not coming to the meeting. Simply bochup! Extra Word MTBF Mean Time Before Failure. Mean time between failures is the predicted elapsed time between inherent failures of a mechanical or electronic system, during normal system operation. MTBF can be calculated as the arithmetic mean time between failures of a system. (Taken from Wikipedia) One Last thing Every day can be a Mother's Day. It doesn't have to be on that Sunday ??‍♂️? https://www.instagram.com/p/Bi4aAmylAlA/?taken-by=hapapaplife

科技最前沿，主要从丘孔语论比较感兴趣的几个领域来谈论科学科技，可能涉及天文、物理、互联网/IT、人工智能/Ai、数码/手机、编程、大数据、商业大佬、创新创业创客、化学、医学、养生、心理学、灵性等领域；认识天地，开阔思维，重塑自我。不要说我涉猎太广泛，只是人生认识自我的过程太过漫长，我们只能先广纳外，然后求诸内，探索着，迷茫着。微信扫码，可以关注公众号丘孔语论，期望与你做更深的交流。盖得排行：无线键盘排行榜盖得排行 2017-03-03 09:20文：盖得排行APP无线连接已成为电子产品的趋势，摆脱有线的束缚，让你想在哪里用键盘，就在哪里用键盘。注：A++最优；A+较优；A优；B中；C差分项指标说明：舒适度：舒适度主要体现为键盘设计是否符合人体工程学。此外，舒适感因人而异，所以是否具有丰富款式可供选择，也是舒适度指标的参考因素之一。续航能力：由无线产品续航时间的长短决定，供电方式（自带充电电池，或需要额外购买干电池）也对此存在影响。连接性能：选用的无线连接方式：2.4G、蓝牙或5G。由连接稳定性高低以及是否支持同时连接多个设备所决定。基本性能：使用寿命主要体现为按键寿命。根据国家标准规定，键盘按键寿命应不小于100万次；键盘平均故障间隔时间(MTBF)的m1应不少于10000h；按键压力为0.54 N±0.14N；特殊功能按键的压力应由产品标准决定；按键键帽的拉拔力应不小于12N，特殊功能按键键帽的拉拔力应由产品标准决定；接触电阻应不大于1 kΩ；按键的抖动时间应不大于15ms；产品应能在直流电压标称值变化±5%的条件下正常工作。NO. 1Logiitech 罗技（瑞典）罗技从为大品牌电脑代工生产鼠标起步，如今是全球最著名的电脑周边设备供应商。作为电脑外设的领导品牌，罗技拥有出色的产品设计能力，Keys-To-Go无线键盘曾获得世界三大设计奖中的IDEA奖和红点奖。除此以外，罗技无线键盘有多达15个产品供用户选择，不仅种类多样，而且拥有多款高端无线产品。其中，罗技K480无线键盘使用两节AAA电池，续航时间长达两年，还能在三个连接设备间自由切换，获得CES创新奖；另一款K800键盘则使用充电电池，连接信号稳定，打字无卡顿，在闲置时可直立放置，节省桌面空间，被PCmag网站选为最佳无线键盘；而K380和K780都以出色的性能在THE WIRECUTTER网站上被评为最佳蓝牙键盘。K380、K480和K780在国内电商平台的售价分别为259元、399元和599元，而K800则需要海淘购买。此外，罗技产品均使用Unifying无线连接技术，只用一个USB接收器就能连接多个罗技产品，在节省了USB接口的同时，还可保证设备间不会互相干扰。作为世界最著名的电脑周边设备供应商，罗技的无线键盘无疑是最优选择。NO. 2Microsoft 微软（美国）实力强大的微软并不局限于软件领域，在电脑配件等硬件领域依然具有相当强大的竞争力。不论有线还是无线键盘，微软最大的优势是其人体工程学设计。在THE WIRECUTTER网站的人体工程学键盘测评中，微软Sculpt人体工学键盘被评为最佳选择，它是目前市面上唯一一款同时具有中部隆起和负角度倾斜设计的键盘，让你的上肢在打字时处于更加自然的状态，可以说是目前市面上舒适度最高的键盘。此外，这款键盘还可拆分键盘布局，使手腕和前臂处于放松位置，而带衬垫的掌托则有利于支撑手腕，半球形的键盘形状又可减少和纠正手腕过度向内弯曲的动作，使手腕以放松、自然的角度摆放其上，减少“鼠标手”的发生。在国内Sculpt键盘搭配Sculpt人体工学鼠标以套件形式出售，售价为899元。对于患有“鼠标手”或有这方面顾虑的用户，微软Sculpt人体工学键盘值得一试。NO. 3RAPOO 雷柏（广东）国内无线键鼠的领导品牌。2008年雷柏科技成为了国内无线键鼠市场占有率第一的品牌，曾连续两年蝉联中国无线键鼠市场占有率榜首位置。作为无线键鼠专家，雷柏拥有13款无线键盘产品，其中无线超薄触控键盘E9270P以出色的外观设计获得了2013年iF工业设计大奖。雷柏出色的无线连接能力，使其无线键盘覆盖了2.4GHz、蓝牙以及5.8GHz无线连接技术，入选TopTenReviews网站十大无线键盘系列产品之列。此外，E9090P还具有无线充电功能，国内售价400元，同样是国产无线键盘中的高品质之选。NO. 4Apple 苹果（美国）继承了苹果公司一贯的极简设计风格，苹果官方推出的无线键盘第二代产品Magic Keyboard同样以其明快的设计抓人眼球。Magic Keyboard可以自动与苹果电脑匹配，使用快捷简便，国内售价728元。除电脑键盘之外，苹果还为iPad Pro推出了无线键盘Smart Keyboard，无需设置，完美搭配iPad Pro，国内售价1288元。对于苹果用户来说，苹果无线键盘就是最佳选择。NO. 5Lenovo 联想(北京)作为全球最大的PC生产厂商，联想同样推出了不少高品质的外设产品。其无线键盘的按键使用寿命超过1000万次，是国家标准的10倍。此外，联想推出的N5902掌中宝是可手持使用的迷你键盘，在键盘手柄处有光学触摸点，可以代替鼠标使用，是一款十分别致的键鼠二合一产品，国内售价285元。NO. 6A4TECH 双飞燕（广东）双飞燕是国内知名的电脑外设品牌，拥有近百项专利技术，双飞燕键盘寿命达到500万次以上，是国家标准的五倍。其键盘使用封胶薄膜电路，具有良好的防水性能，无线传输距离最远可达15米，而且带有主动跳频防干扰技术，一旦检测到有同一频段的其它无线设备，就会主动跳频，防止互相干扰，国内售价99至179元不等。NO. 7Fühlen 富勒（广东）富勒是国产电脑外设品牌，与欧洲第二大电脑公司-德国FTS技术解决中心保持技术合作关系，使用FAPP自动化机器人生产技术，其按键寿命超过1000万次，是国家标准的10倍。此外，富勒L460S还具有独立背光灯款和智能人手识别技术，更有利于在昏暗的环境下的使用。其无线键盘系列在国内售价为79至139元不等。NO. 8Dell 戴尔（美国）作为主流Windows电脑生产商，戴尔的电脑周边配件设备同样品质可靠。戴尔无线键盘采用紧凑型设计，尺寸小于普通键盘。这种紧凑型设计能够让使用键鼠的双手更加靠近，更接近自然姿态，从而缓解长时间工作带来的肩部酸痛。而且戴尔键盘可以续航使用12个月，无须频繁更换电池，国内售价129至299元不等。NO. 9Delux 多彩（广东）多彩科技创建于1994年，专注于电竞外设和电脑周边产品生产，并且是苹果和英特尔的合作伙伴。在国内，多彩科技跟联想、方正、清华同方、TCL等厂商一直保持合作关系。多彩旗下无线键盘品类丰富，从超薄、巧克力键帽、高效布局设计，到防水、防尘、静音等各项功能均有覆盖。此外，多彩还为iPad推出了多款铝合金材质蓝牙键盘，外观接近iPad设计风格，国内售价599元。NO.10B.O.W. 航世（广东）航世BOW是国内从事蓝牙键盘研发的无线产品专业户，与德国QTEC公司签订技术合作协议，引进德国生产技术工艺。包括iPad专用键盘，航世一共推出了14款无线键盘。航世键盘采用美国博通蓝牙芯片，可以快速稳定地与电脑连接。其可折叠键盘方便携带，经测试折叠寿命在5年以上，国内售价300至370元。查看更多榜单或文章，欢迎下载盖得排行APP，或者关注盖得排行微信公众号【 guiderank 】

What To Do When A Customer Requests MTBF You have carefully crafted a detailed reliability goal including function, environment, probability, and duration, plus apportioned it to critical supplied subsystems and components. Your vendor decides to use MTBF instead. What can you do? What should you do? The supplier is critical to the success of the […] The post What To Do When A Customer Requests MTBF appeared first on Accendo Reliability.

Time to Failure Data Analysis for Your Factory Equipment We have data. Often an abundance of data concerning equipment failures. Failures per month or MTBF type measures do not reveal sufficient insights to understand the pattern of failures. We need to know if the rate of failures is increasing or not if the maintenance program […] The post Time to Failure Data Analysis for Your Factory Equipment appeared first on Accendo Reliability.

Mean Time Between Failure or MTBF is almost universally recognized in maintenance, but should you use it? No! Find out why. The post 04 – What is MTBF and Why You Shouldn’t Use It appeared first on Accendo Reliability.

Fred Schenkelberg, Blogger Tim Rodgers interviews Fred Schenkelberg concerning his blog, No MTBF and his mission to eradicate the common misuse of MTBF. Fred Schenkelberg is a reliability engineering and management consultant at FMS Reliability. He s a lecturer at the University of Maryland, and he s been an active contributor to both the IEEE and the […] The post DTK Fred Schenkelberg Blogger appeared first on Accendo Reliability.

You may already know my position on MTBF. If not, in short, do not use MTBF at all, ever, in any form. So what should we use instead. I suggest using reliability, the probability of success over a specific duration. Let s discuss what will work for you. The post Exploring Alternatives to MTBF appeared first on Accendo Reliability.

If you have multiple G-mail accounts, now you can monitor all of them in a single browser session. Does your computer need a new fan? Instead of meantime between failures, manufacturers are now talking about AFRs. In Short Circuits, Intel goes for anti-virus, Google retreats in Germany, Network Solutions serves problems, and a new Nikon SLR does video.