Microsoft Technology Licensing, LLC

Aaron Edward Dietrich

Alexander Kirshenbaum

Cenk Ergan

Michael Richard Fortin

Lena Berg

Sarah J D'Onofrio

Mehmet Iyigun

Yevgeniy Bak

Robert P Fitzgerald

Jason L Cohen

Matthew Robert Ayers

Charles T Lenzmeier

Steve K Lim

Taylor Paul Spangler

Levent Ozgur

Timothy James Chapman

Van Stephen Lanning

Ben Mickle

Sylvain Goyette

Swamy V P L N Nallamalli

Alex Pung Leung

Jareth Leigh Day

Dallas Allen Warren

William Tigard Baker

Aspects of the disclosure include methods and systems for performing automated fault scenario generation for chaos engineering. Aspects include obtaining a configuration of a service under test, obtaining a first plurality of fault scenarios, and applying each of the first plurality of fault scenarios to the service under test. Aspects also include recording telemetry data regarding an operation of the service under test under each of the fault scenarios, selecting, based on the telemetry data, a first fault scenario from the fault scenarios, and generating a second plurality of fault scenarios. Aspects further include applying each of the second plurality of fault scenarios to the service under test, recording telemetry data regarding the operation of the service under test under each of the second plurality of fault scenarios, and identifying a vulnerability of the service under test based on the recorded telemetry data.

Automated fault scenario generation for chaos engineering

The technology described herein provides an automated software-testing platform that functions in an undefined action space. The technology described herein starts with an undefined action space but begins to learn about the action space through random exploration. Both the action taken during testing and the resulting state may be communicated to a centralized testing service. The technology described herein also mines the action telemetry data and state telemetry data to identify action patterns that produce a sought after result. Once a plurality of action patterns is identified and, at least, a partial model of the action space is built, the testing on the test machines may be split into random test mode, replay test mode, and a pioneering test mode.

Automated software testing

A behavior detection system has access to a collection of behavior definitions that each describe a functional behavior of a system. Each behavior definition includes multiple basic operations, each of which includes an identifier and one or more parameters. The behavior definition also includes, explicitly or inherently, a basic operation combination definition that describes a sequence or other manner in which the basic operations are combined. The behavior detection system analyzes events in an event log for the system and determines whether the events in the event log satisfy any of the behavior definitions. An appropriate responsive action is taken in response to detecting that the events in the event log satisfy a behavior definition. The collection of behavior definitions is scalable, allowing behavior definitions to be added or deleted, and allowing basic operations in a behavior definition to be changed (e.g., adding, removing, and/or modifying basic operation parameters).

Scalable automated detection of functional behavior

A collaborative diagnostic system monitors events in a system and identifies a causality chain from a detected performance issue to the root cause of that performance issue. The collaborative diagnostic system includes multiple issue detectors, multiple analysis core modules, and multiple scenario modules that work together to identify the causality chain and root cause. Each issue detector is a module or component that includes logic to detect known behaviors in the system, such as performance issues in the system. Each analysis core module includes logic to analyze and correlate low level system behavior within a conceptual area. Within each analysis core module are one or more diagnostic modules that are specific to that analysis core module to help determine what is happening in the system. Each scenario module includes logic to take an appropriate responsive action in response to the root cause of a performance issue being determined.

Modularized collaborative performance issue diagnostic system

Techniques for conducting an automated analysis of operations carried out during the critical path for a usage scenario and suggesting ways in which the configuration of the computing device could be changed to affect performance of the computing device. Computing devices can be operated in a variety of usage scenarios and users may notice the performance of a computing device in certain usage scenarios more particularly. Critical path analysis of operations conducted in these usage scenarios can be used to identify a critical path of the usage scenario, from which changes that could be made to the computing device to affect performance could be identified. Once the changes that could be made are identified, suggestions can be made to the user, such that a user is able to make changes to the configuration to affect performance when the user has little knowledge about how to improve configurations.

Analyzing performance of computing devices in usage scenarios

A method and apparatus for managing the caching of data on an auxiliary memory of a computer. Pages of data may be cached on an auxiliary memory, such as a flash memory, at a virtual level using an identifier that does not involve a physical address of the pages on a memory. Pages may be cached on auxiliary memory that may be removable from the computer, e.g., by unplugging the memory from the computer. Page data may be encrypted and/or compressed on the auxiliary memory. An authentication indicator may be used to verify the accuracy of cached data in the case of an interrupted connection to the auxiliary memory, e.g., as a result of computer power down, hibernation, removal of the memory from the computer, etc.

Management of external memory functioning as virtual cache

Increased efficiency in booting a computer uses a process of logging physical-level disk access during a boot cycle for use in creating a boot plan for a subsequent boot. Processing the log from one or more previous boots removes unnecessary reads such as those associated with temporary files and then orders the remaining read accesses based on times of prior read accesses and and by physical location on the disk. Upon boot, data likely to be requested first orders the remaining read accesses based on times of prior read accesses and By taking advantage of disk head and platter characteristics, data is read in sweeps through the disk, reducing overall latency. Requests that are not in cache may be held if the data is already scheduled for retrieval.

Accelerated system boot

Growing community of inventors

Kirkland, WA, United States of America

Aaron Edward Dietrich