Contract type
Web / Internet Service
Company Type
外資系企業/Foreign Company
6 Million yen〜8 Million yen
Japanese Level
ビジネスレベル/Business Level
English Level
日常会話レベル/Daily Conversational Level
Other Language Skills

Job Description

<Business description> ・ Utilization of public cloud and SaaS ・ The company's service is currently built on AWS and GCP. ・ They are actively using SaaS for non-core parts as a service. ・ Datadog for monitoring, Sendgrid for email, Sentry for error management, etc. ・ Infrastructure as Code (coding, automation) ・ Infrastructure construction is coded and automated using tools such as Terraform and Ansible as much as possible. ・ Utilization of OSS ・ Kubernetes, Envoy, Argo CD, Ruby, Ruby on Rails, Go, gRPC, PostgreSQL, MongoDB, fluentd, etc. Quipper's services are supported by many OSS. ・ It is recommended not only to use OSS, but also to be actively involved in issue reporting and plug-in creation as needed. ・ Write code ・ If it makes sense to use an existing solution without writing code, do so, and if it makes sense to make it yourself, do so. <Charm of position> The company is currently undergoing a gradual transition from a monolithic architecture to microservices. This is not only a technical problem, but also an organizational problem, and it is a problem to advance product development and explore better education. The importance of various DevOps / SRE practices is becoming apparent. In the transition to microservices, the major issue for the entire development organization, including SRE, is "self-sufficiency." Since the same service is shared by multiple teams, releasing features requires complex tweaking. Also, when creating new services, for example, it is necessary to coordinate with SRE to set up the necessary infrastructure, and it has become difficult to achieve the required speed. "Self-contained" is to break through that. If each team can have services according to their responsibilities, the cost of adjustment can be as close to zero as possible, and the cycle of function development that they need can be repeated many times at low cost. Through that, we should be able to make more correct products. In addition, if technology selection in the infrastructure layer can be performed within the development team, it will be possible to quickly verify the optimum options for the required functions, and the knowledge of the infrastructure cultivated in this way will not be available until then. It may even bring out a completely different way of functioning. The SRE team required in such an organization is not just to fulfill the request, but to improve the product by empowering the development organization. Whether it's the move to microservices or the self-sufficiency of the team, these challenges are endless and the bottlenecks in question are constantly changing. It may happen that the microservices cut out from the monolith become monoliths again and need to be cut out again. Under such circumstances, the only thing that can be done is to set issues through daily dialogue with the development team and team members, clarify the goals for them once, and work on them one by one. However, if you clear one task, you will see another task. Still, the software that comes out of it, the value that reaches users, and the self and team that have grown to realize it may be there. [Technology / Tools] Databases: MongoDB, Amazon Aurora (PostgreSQL / MySQL), BigQuery, Treasure Data Infrastructure: AWS, GCP, Kubernetes, CircleCI Communication: GitHub, Slack

Required skills

Create a program to learn the ideas and skills of Site Reliability Engineering with the development team and explore better product development. <Required conditions> Experience in operating automation mechanisms through Infrastructure as Code, etc. using configuration management tools on AWS Experience in operating web applications Experience writing programming languages ​​other than shell scripts (Go language, Ruby, Python, etc.) Experience using container-related technologies such as Docker Being able to sympathize with the mission of "Distributors of Wisdom" and "the distribution revolution of knowledge" and the style of engineering. Those who can make better things by communicating interactively with each person concerned in work that is not closed to SRE such as product development If Japanese is not your mother tongue, those who have language proficiency equivalent to N1 <Welcome conditions> Worked in a team that practices DevOps and has experience developing products from both Dev / Ops perspectives Have created a culture of deciding SLI / SLO and reviewing them Experience in improving the Developer Experience through building CI / CD pipelines and standardizing the development environment Experience in thinking, implementing, and evolving architecture from both organizational and technical perspectives We have the know-how to operate and operate distributed systems such as Microservices in a stable manner. Experience in building the foundation for ensuring Observability such as Logging, Tracing, Metrics, etc. Experience in cloud-specific design of in-house services You can make an appropriate selection from multiple databases such as RDBMS / KVS / column-oriented DB according to the required requirements and characteristics. Experience in building analytical infrastructure Experience programming in Ruby and Go Have or want to improve your communication skills in English Experience in properly assessing security risks and addressing issues