Enterprises have paid attention to consortium blockchains like Hyperledger Fabric, which is one of the most promising platforms, for efficient decentralized transactions without depending on any particular organization. A consortium blockchain-based system will be typically built across multiple organizations. In such blockchain-based systems, system operations across multiple organizations in a decentralized manner are essential to maintain the value of introducing consortium blockchains. Decentralized system operations have recently been becoming realistic with the evolution of consortium blockchains. For instance, the release of Hyperledger Fabric v2.x, in which individual operational tasks for a blockchain network, such as command execution of configuration change of channels (Fabric's sub-networks) and upgrade of chaincodes (Fabric's smart contracts), can be partially executed in a decentralized manner. However, the operations workflows also include the preceding procedure of pre-sharing, coordinating, and pre-agreeing the operational information (e.g., configuration parameters) among organizations, after which operation executions can be conducted, and this preceding procedure relies on costly manual tasks. To realize efficient decentralized operations workflows for consortium blockchain-based systems in general, we propose a decentralized inter-organizational operations method that we call Operations Smart Contract (OpsSC), which defines an operations workflow as a smart contract. Furthermore, we design and implement OpsSC for blockchain network operations with Hyperledger Fabric v2.x. This paper presents OpsSC for operating channels and chaincodes, which are essential for managing the blockchain networks, through clarifying detailed workflows of those operations. A cost evaluation based on an estimation model shows that the total operational cost for executing a typical operational scenario to add an organization to a blockchain network having ten organizations could be reduced by 54 percent compared with a conventional script-based method. The implementation of OpsSC has been open-sourced and registered as one of Hyperledger Labs projects, which hosts experimental projects approved by Hyperledger.

Managing SaaS systems requires administrators to monitor and analyze diverse types of log data collected from a variety of components such as applications and IT resources. Integrated monitoring systems, enabled with datastore capable of storing and query-based processing of semi-structured data (e.g., NOSQL - some specific document database), is a promising solution that can store and query any type of log data with a single unified set of management panes. However, due to the increasing scale of SaaS systems and their long service lives, integrated monitoring systems have faced the problems in response times of log analysis and storage consumption for logs. In this present work, we solve the problems by developing an efficient log management method for SaaS systems. Our empirical observation is that the problems are primarily derived from the unselective log processing of datastore, whereas there should be heterogeneities in log data that we can take advantage of for efficient log management. Based on this observation, we first confirm this insight by investigating the usage patterns of log data in a quantitative manner with an actual dataset of log access histories obtained from a SaaS system serving tens of thousands of enterprise users over the course of more than 1.5 years. We show that there are heterogeneities in required retention period of logs, response time of log analysis, and amount of data, and the heterogeneities depend on log data category and its analysis scenario. Armed with the evidence of the heterogeneities in log data and the usage patterns found from the investigation, we design a methodology of context-aware log data management, key features of which are to speculatively pre-cache the result of log analysis and to proactively archive log data, depending on log data category and analysis scenario. Evaluation with a prototype implementation shows that the proposed method reduces the response time by 47% compared to a conventional method and the storage consumption by approximately 40% compared to the original log data.